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

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

Симптом

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

Эта ошибка означает, что 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 не настроен для приема запросов на виртуальном хосте, указанном в сообщении об ошибке. Пользователи Edge Public и Private Cloud
Виртуальный хост удален в новой развернутой версии прокси API. Эту проблему может вызвать удаление виртуального хоста из недавно развернутой версии, когда клиент все еще использует конкретный виртуальный хост. Пользователи Edge Public и Private Cloud
Путь не связан ни с каким прокси-сервером API Конкретный прокси-сервер API не настроен для приема запросов по пути, указанному в сообщении об ошибке. Пользователи Edge Public и Private Cloud
Прокси-сервер API не развернут в среде Конкретный прокси-сервер API не развертывается в конкретной среде, в которой вы пытаетесь выполнить запросы API. Пользователи Edge Public и Private Cloud
Среда не загружена в процессор сообщений Конкретная среда (в которой вы пытаетесь выполнить запросы API) не была загружена в процессоры сообщений из-за ошибки. Пользователи Edge Private Cloud
Прокси-сервер API не развернут на одном или нескольких процессорах сообщений. Прокси-сервер API может быть не развернут на одном или нескольких процессорах сообщений из-за отсутствия уведомления о событии во время развертывания. Пользователи Edge Private Cloud

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

Журналы NGINX и процессора сообщений помогут устранить ошибку 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. Проверьте конфигурацию конечной точки прокси-сервера для прокси-сервера 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>

    Пример конфигурации конечной точки прокси-сервера, показывающий добавление по умолчанию> 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 :
      • Виртуальные хосты, настроенные в конечной точке прокси в версии 5. 
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • Виртуальные хосты, настроенные в конечной точке прокси в версии 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. И если path suffix , указанный в URL-адресе запроса API, не соответствует ни одному из условий, это и есть причина ошибки.
  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.

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

    • Если http://myorg-prod.apigee.net/weather — ваш URL-адрес, то 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. Если вы являетесь пользователем Public Cloud, предоставьте следующую информацию:
    • Название организации
    • Имя среды
    • Имя прокси 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. Подробная информация о том, какие разделы этого руководства вы пробовали, а также любые другие сведения, которые помогут нам ускорить решение этой проблемы.