404 Невозможно определить прокси-сервер для хоста: <имя виртуального хоста> и URL: <path>

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

Симптом

В ответ на вызовы API клиентское приложение получает HTTP-статус 404 с сообщением Not Found и сообщением об ошибке Unable to identify proxy for host: VIRTUAL_HOST and url: PATH .

Эта ошибка означает, что Edge не смог найти прокси-сервер API для указанного виртуального хоста и пути.

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

Вы получите следующий код состояния HTTP:

HTTP/1.1 404 Not Found

Вы также увидите сообщение об ошибке, похожее на показанное ниже:

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

Приведенное выше сообщение об ошибке указывает на то, что Edge не смог найти API-прокси для виртуального хоста default и пути /oauth2/token .

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

Ниже перечислены некоторые из возможных причин этой ошибки:

Причина Описание Инструкции по устранению неполадок, применимые для
API-прокси не связан с конкретным виртуальным хостом. Конкретный API-прокси не настроен для приема запросов на виртуальном хосте, указанном в сообщении об ошибке. Пользователи публичных и частных облачных сервисов на периферии сети
В новой версии API-прокси удален виртуальный хост. Удаление виртуального хоста из недавно развернутой версии, пока клиент все еще использует этот конкретный виртуальный хост, может вызвать эту проблему. Пользователи публичных и частных облачных сервисов на периферии сети
Путь не связан ни с одним API-прокси. Конкретный API-прокси не настроен для приема запросов по пути, указанному в сообщении об ошибке. Пользователи публичных и частных облачных сервисов на периферии сети
API-прокси не развернут в среде Конкретный API-прокси развернут не в той среде, в которой вы пытаетесь отправлять API-запросы. Пользователи публичных и частных облачных сервисов на периферии сети
Окружение не загружено в обработчик сообщений. Конкретная среда (в которой вы пытаетесь отправлять запросы к API) не была загружена в обработчики сообщений из-за ошибки. Пользователи Edge Private Cloud
API-прокси не развернут на одном или нескольких обработчиках сообщений. API-прокси может быть не развернут на одном или нескольких обработчиках сообщений из-за отсутствия уведомлений о событиях во время развертывания. Пользователи Edge Private Cloud

Общие этапы диагностики

Журналы NGINX и Message Processor помогут в устранении ошибки 404 Для проверки журналов выполните следующие действия:

  1. Просмотреть журналы NGINX можно с помощью следующей команды:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. Проверьте наличие следующих полей в записях журнала:
    Поле Ценить
    Upstream_status, status 404
    X-Apigee-fault-code messaging.adaptors.http.flow.ApplicationNotFound

    Запишите идентификатор сообщения из журналов.

  3. Проверьте журналы обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log) , чтобы узнать, есть ли у вас messaging.adaptors.http.flow.ApplicationNotFound для конкретного API или уникальный идентификатор сообщения из шага 2 для запроса к API.

    Пример сообщения об ошибке из журнала обработчика сообщений. 

    4. NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

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

    code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

Причина: API-прокси не связан с конкретным виртуальным хостом.

Если API-прокси не настроен на прием запросов для конкретного виртуального хоста, то может быть получен ответ 404 Not Found с сообщением об ошибке Unable to identify proxy for host: VIRTUAL_HOST and url: PATH .

Диагноз

  1. Проверьте конфигурацию Proxy Endpoint для API-прокси и убедитесь, что API-прокси настроен на прием запросов к виртуальному хосту, указанному в сообщении об ошибке. Это определяется элементом VirtualHost . Давайте рассмотрим пример конфигурации ProxyEndpoint , чтобы это понять.

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

  2. Предположим, что виртуальные хосты в конкретной среде определены следующим образом:
    Имя Порт Псевдоним хоста
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. Вы отправляете API-запрос к VirtualHost default , используя URL-адрес http://myorg-prod.apigee.net/weather
  4. Поскольку ProxyEndpoint не имеет VirtualHost default , как показано в примере выше, вы получаете код ответа 404 со следующим сообщением об ошибке: 
    {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  5. Для решения этой проблемы перейдите в раздел «Решение» ниже.
  6. Если ProxyEndpoint настроен на прием запросов на VirtualHost default , перейдите к следующей причине — Путь не связан ни с одним API-прокси .

Разрешение

  1. Для решения проблемы добавьте отсутствующий VirtualHost в конфигурацию ProxyEndpoint . В приведенном выше примере вы можете добавить VirtualHost по умолчанию в конфигурацию ProxyEndpoint следующим образом:
    <VirtualHost>default</VirtualHost>

    Пример конфигурации конечной точки прокси, демонстрирующий добавление виртуального хоста по умолчанию.

  2. В качестве альтернативы, в приведенном выше примере, если вы намеревались использовать только secure VirtualHost для этого конкретного API-прокси, то отправляйте API-запросы только к secure VirtualHost используя протокол HTTPS: 
    https://myorg-prod.apigee.net/weather

Причина: Виртуальный хост удален в новой версии API-прокси.

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

Диагноз

  1. Проверьте конфигурацию конечной точки прокси- сервера API, чтобы убедиться, что прокси-сервер API настроен на прием запросов для виртуального хоста, указанного в сообщении об ошибке. Это указывает элемент VirtualHost в конфигурации ProxyEndpoint .
  2. Если указанный в сообщении об ошибке виртуальный хост не существует в конфигурации ProxyEndpoint , выполните следующие действия. В противном случае перейдите к следующей причине — Путь не связан ни с одним API-прокси .
  3. Сравните конфигурацию ProxyEndpoint ранее развернутой версии с конфигурацией текущей развернутой версии.
    1. Например, предположим, что ранее развернутая вами версия была 5 , а текущая — 6 :
      • Виртуальные хосты, настроенные в Proxy Endpoint в версии 5. 
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • Виртуальные хосты, настроенные в Proxy Endpoint в версии 6. 
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. В приведенном выше примере VirtualHost vh1 существовал в revision 5, но был удален в revision 6 и заменен на VirtualHost secure .
    3. Таким образом, если вы или ваши клиенты отправляете запросы к этому API-прокси с помощью VirtualHost vh1 (который был частью revision 5 ), вы получите код ответа 404 со следующим сообщением об ошибке: 
      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  4. Проверьте, было ли изменение виртуального хоста внесено преднамеренно или непреднамеренно в текущей развернутой версии, и примите соответствующие меры, как описано в разделе «Решение» .

Разрешение

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

Сценарий №1: Преднамеренное изменение

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

  1. Создайте новый прокси-сервер с другим базовым путем и используйте другой виртуальный хост (которого нет в ранее развернутой версии).

  2. Если вы хотите продолжать использовать существующий API-прокси, но с другим виртуальным хостом, то лучше сохранить существующий виртуальный хост и добавить дополнительный виртуальный хост.

    Это гарантирует, что пользователи данного API-прокси не пострадают от изменений.

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

    Это гарантирует, что пользователи данного API-прокси будут осведомлены об изменении и смогут использовать другой виртуальный хост для выполнения вызовов к этому API-прокси. Следовательно, это изменение их не затронет.

Сценарий №2: Непреднамеренные изменения

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

  1. Обновите конфигурацию ProxyEndpoint в текущей развернутой версии, чтобы использовать те же виртуальные хосты, которые использовались в предыдущей развернутой версии. В приведенном выше примере измените следующий раздел:
    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

    к 

    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
  2. Повторно разверните измененную версию.

Передовые методы

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

Причина: Путь не связан ни с одним API-прокси.

Если API-прокси не настроен на прием запросов по указанному пути в URL-адресе API-запроса, то может быть получен ответ 404 Not Found с сообщением об ошибке Unable to identify proxy for host: VIRTUAL_HOST and url: PATH .

Диагноз

  1. Проверьте конфигурацию ProxyEndpoint для конкретного API-прокси, через который вы намеревались отправлять API-запросы.
  2. Проверьте, настроен ли API-прокси на прием запросов по указанному в сообщении об ошибке пути. Это можно сделать, выполнив действия, описанные в Сценарии № 1 и № 2 .

Сценарий №1: Путь не соответствует базовому пути API-прокси.

  1. Если path , указанный в сообщении об ошибке, не совпадает с basepath конкретного API-прокси или не начинается с basepath , то это может быть причиной ошибки.
  2. Давайте рассмотрим пример, чтобы это объяснить:
    1. basepath к предполагаемому API-прокси — /weather
    2. URL-адрес запроса API — https://myorg-prod.apigee.net/climate . Это означает, что путь, используемый в URL-адресе запроса API, — /climate.
  3. В этом примере path не совпадает с basepath и не начинается с basepath . Поэтому возникает следующая ошибка: 
    {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

Разрешение

  1. Убедитесь, что path используемый в URL-адресе вашего API-запроса, совпадает с basepath конкретного API-прокси.
  2. В приведенном выше примере URL-адрес API-запроса должен выглядеть следующим образом: 
    {
https://myorg-prod.apigee.net/weather

Сценарий №2: Путь не соответствует ни одному из доступных условных потоков.

  1. Если path , используемый в URL-адресе API-запроса, начинается с basepath , то возможно, что path suffix (часть, которая следует за basepath ), указанный в сообщении об ошибке, не соответствует ни одному из условных сценариев, что может вызвать ошибку 404 .
  2. Давайте рассмотрим пример, чтобы это объяснить:
    1. basepath к предполагаемому API-прокси — /weather
    2. URL-адрес запроса API — https://myorg-prod.apigee.net/weather/Delhi . Это означает, что путь, используемый в URL-адресе запроса API, — /weather/Delhi.
  3. В этом примере path начинается с basepath /weather . Кроме того, он имеет path suffix /Delhi .
  4. Теперь проверьте, есть ли в ProxyEndpoint какие-либо условные потоки.
  5. Если условных потоков нет или есть несколько безусловных потоков, перейдите к следующей причине — API-прокси не развернут в среде .
  6. Если ProxyEndpoint содержит только условные потоки, проверьте следующее:
    1. Если во всех этих условных потоках выполняется проверка наличия определенного proxy.pathsuffix (пути после базового пути).
    2. Если указанный в URL-адресе API-запроса path suffix не соответствует ни одному из условий, то это и является причиной ошибки.
  7. Допустим, у нас есть два потока в ProxyEndpoint , и оба являются условными, как показано ниже: 
    <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
    1. В приведенном выше примере у нас есть два условных потока: один соответствует proxy.pathsuffix (путь после базового пути) /Bangalore , а другой — /Chennai . Но ни один из них не соответствует /Delhi , который является path suffix , переданным в URL-адресе API-запроса.
    2. Это причина ошибки 404 Поэтому вы получите следующую ошибку: 
      {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

Разрешение

  1. Убедитесь, что path suffix соответствует хотя бы одному из условных потоков в вашей прокси-конечной точке.
  2. В приведенном выше примере для устранения ошибки можно использовать один из следующих подходов:
    1. Если вы хотите выполнить определенный набор политик для пути /Delhi , добавьте отдельный поток с необходимым набором политик и убедитесь, что условие соответствует /proxy.pathsuffix /Delhi как показано ниже: 
      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
    2. Если вы хотите выполнить общий набор политик для пути /Delhi , то в общем потоке убедитесь, что существует условие, разрешающее общий /proxy.pathsuffix . То есть, оно должно разрешать любой путь после basepath /weather как показано ниже: 
      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

Если ProxyEndpoint имеет правильный basepath , и path suffix указанный в URL-адресе API, соответствует одному из условных потоков, то переходите к следующей причине — API-прокси не развернут в среде .

Причина: API-прокси не развернут в среде.

Диагноз

  1. Определите среду, к которой относится псевдоним хоста, используемый в URL-адресе вашего API-запроса. Это можно сделать, проверив сведения обо всех виртуальных хостах в каждой из сред вашей организации в пользовательском интерфейсе Edge.

    Например, предположим следующую конфигурацию:

    • Если ваш URL-адрес — http://myorg-prod.apigee.net/weather , то myorg-prod.apigee.net — это псевдоним хоста.
    • Псевдоним хоста myorg-prod.apigee.net настроен как часть одного из виртуальных хостов в prod среде вашей организации.
  2. Проверьте, развернут ли конкретный API-прокси в среде, определенной на шаге 1 выше.
  3. Если API-прокси не развернут в конкретной среде, то это и является причиной ошибки 404 .
    1. Итак, в примере, использованном на шаге 1 выше, предположим, что API-прокси не развернут в prod среде, тогда это и является причиной ошибки.
    2. Перейдите в раздел «Решение» ниже.
  4. Если API-прокси развернут в данной среде, перейдите к следующей причине — Среда не загружена в обработчики сообщений .

Разрешение

Разверните API-прокси в той среде, в которой вы планируете отправлять API-запросы.

Причина: Окружение не загружено в обработчики сообщений.

Диагноз

  1. Войдите в каждый из обработчиков сообщений и проверьте, загружена ли в обработчике сообщений конкретная среда, в которой вы отправляете запрос к API, используя следующую команду: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
  2. Если конкретная среда указана в приведенной выше команде, перейдите к следующей причине — API-прокси не развернут на одном или нескольких обработчиках сообщений .
  3. Если конкретная среда не указана в списке, проверьте файлы /opt/apigee/var/log/edge-message-processor/logs/system.log и /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log на процессорах сообщений на наличие ошибок, возникших во время загрузки сред.
  4. Причиной сбоя загрузки среды в обработчик сообщений может быть множество различных ошибок. Решение зависит от возникшей ошибки.

Разрешение

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

  1. Если в журнале обработчика сообщений вы видите одну из следующих ошибок, это означает, что проблема связана с сертификатами/ключами, добавленными в указанное хранилище ключей/доверенных сертификатов в указанной среде.

    Ошибка #1: java.security.KeyStoreException: Невозможно перезаписать собственный сертификат 

    2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
…
Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]

    ... 20 common frames omitted 

    2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

    Ошибка #2: java.security.KeyStoreException: Невозможно перезаписать секретный ключ 

    2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
...
Caused by: java.security.KeyStoreException: Cannot overwrite secret key
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
... 20 common frames omitted

2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert
  2. Получите подробную информацию о хранилище ключей/доверенных сертификатов, указанном в сообщении об ошибке, показанном на предыдущем шаге, используя следующий вызов API управления: 
    curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

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

    {
   "certs":[
      "mycert",
      "mycert-new"
   ],
   "keys":[
      "mycert"
   ],
   "name":"myTruststore"
}
  3. В приведенном примере показано, что в хранилище доверенных сертификатов myTruststore находятся два сертификата и ключ. Обычно хранилище доверенных сертификатов не содержит ключа. Если же оно содержит ключ, лучше иметь один сертификат и один ключ.
  4. Получите подробную информацию о двух сертификатах, используя следующий API: 
    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
  5. Проверьте срок действия каждого из сертификатов и определите, какой из них просрочен/старее.
  6. Удалите просроченный или ненужный сертификат из хранилища доверенных сертификатов myTruststore .

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

Причина: API-прокси не развернут на одном или нескольких обработчиках сообщений.

API-прокси может быть не развернут на одном или нескольких обработчиках сообщений. Эта проблема возникает крайне редко и чаще всего связана с отсутствием уведомления о событии от сервера управления к обработчику сообщений во время развертывания конкретного API-прокси. В этом случае вы также не сможете создать сеанс трассировки в пользовательском интерфейсе Edge.

Диагноз

  1. Войдите в каждый из обработчиков сообщений и проверьте, развернута ли конкретная версия прокси-сервера API, используя следующую команду: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  2. Если конкретная версия API-прокси не отображается в выводе команды, упомянутой в шаге 1 выше, перезапустите соответствующий обработчик сообщений, как описано в разделе «Решение» .
  3. Повторите шаги 1-2 для всех обработчиков сообщений.
  4. Если конкретная версия API-прокси развернута на всех обработчиках сообщений, то это не является причиной проблемы. Перейдите к разделу «Необходимо собрать диагностическую информацию» .

Разрешение

Перезапустите те обработчики сообщений, на которых не развернута конкретная версия API-прокси. 

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

Диагностика проблем с помощью мониторинга API.

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

Для решения этой проблемы перейдите на страницу «Мониторинг API > Исследование» , выберите соответствующую дату, прокси и т. д., и вы увидите следующие сведения:

Fault code and status code in UI

  • Код ошибки: messaging.adaptors.http.flow.ApplicationNotFound
  • Код состояния: 404
  • Источник неисправности: Apigee или MP

Кроме того, вы можете нажать кнопку «Просмотреть журналы», как показано на скриншоте выше, и проверить все подробнее.

view logs

В этом примере показано, как устранять проблемы с кодами 5xx в ваших API с помощью мониторинга API. Например, вы можете настроить оповещение, которое будет отправляться, когда количество кодов состояния 404 превысит определенный порог.

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

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

  1. Если вы являетесь пользователем публичного облака, предоставьте следующую информацию:
    • Название организации
    • Название среды
    • Имя API-прокси
    • Выполните команду curl для воспроизведения ошибки.
  2. Если вы являетесь пользователем частного облака, предоставьте следующую информацию:
    • Полное сообщение об ошибке
    • Название среды
    • пакет API-прокси
    • Журналы обработчика сообщений /opt/apigee/var/log/edge-message-processor/logs/system.log
    • Результаты выполнения следующих команд на каждом из обработчиков сообщений. 
      • curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
      curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  3. Пожалуйста, укажите, какие разделы этого руководства вы уже пробовали, а также любые другие замечания, которые помогут нам ускорить решение этой проблемы.