404 Impossible d'identifier le proxy pour l'hôte: <nom d'hôte virtuel> et l'URL: <chemin>

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Problème constaté

L'application cliente reçoit un code d'état HTTP 404 avec le message Not Found et le message d'erreur Unable to identify proxy for host: VIRTUAL_HOST and url: PATH en réponse aux appels d'API.

Cette erreur signifie qu'Edge n'a pas trouvé le proxy d'API pour l'hôte virtuel et le chemin d'accès spécifiés.

Message d'erreur

Vous recevrez le code d'état HTTP suivant :

HTTP/1.1 404 Not Found

Un message d'erreur semblable à celui ci-dessous s'affichera également :

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

Le message d'erreur ci-dessus indique qu'Edge n'a pas trouvé le proxy d'API pour l'hôte virtuel default et le chemin d'accès /oauth2/token.

Causes possibles :

Voici quelques-unes des causes possibles de cette erreur :

Étapes de diagnostic courantes

Les journaux NGINX et du processeur de messages seront utiles pour résoudre l'erreur 404. Pour vérifier les journaux, procédez comme suit :

1. Affichez les journaux NGINX à l'aide de la commande suivante :

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

2. Recherchez les champs suivants dans les entrées de journal :

   Champ	Valeur
   Upstream_status, status	404
   X-Apigee-fault-code	messaging.adaptors.http.flow.ApplicationNotFound

   Notez l'ID du message dans les journaux.

3. Consultez les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)) pour voir si vous disposez de messaging.adaptors.http.flow.ApplicationNotFound pour l'API spécifique ou si vous avez l'ID de message unique de l'étape 2 pour la requête d'API.

   Exemple de message d'erreur du journal du processeur de messages

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)

Le journal ci-dessus indique le code d'erreur et le message d'erreur suivants :

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

Cause : Le proxy d'API n'est pas associé à l'hôte virtuel spécifique.

Si le proxy d'API n'est pas configuré pour accepter les requêtes pour l'hôte virtuel spécifique, nous pouvons obtenir une réponse 404 Not Found avec le message d'erreur Unable to identify proxy for host: VIRTUAL_HOST and url: PATH..

Diagnostic

1. Vérifiez la configuration du point de terminaison du proxy pour le proxy d'API et déterminez si le proxy d'API est configuré pour accepter les requêtes pour l'hôte virtuel spécifié dans l'erreur. Cela est indiqué par l'élément VirtualHost. Pour comprendre, examinons un exemple de configuration ProxyEndpoint.

   Exemple de configuration de point de terminaison de proxy montrant que le proxy d'API accepte les requêtes sur un hôte virtuel sécurisé

   

2. Supposons que les hôtes virtuels soient définis dans l'environnement spécifique comme suit :

   Nom	Port	Alias d'hôte
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. Vous envoyez une requête API à l'default VirtualHost à l'aide de l'URL http://myorg-prod.apigee.net/weather
4. Comme ProxyEndpoint ne comporte pas default VirtualHost, comme le montre l'exemple ci-dessus, vous obtenez le code de réponse 404 avec le message d'erreur suivant :

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

5. Pour résoudre ce problème, consultez la section Résolution ci-dessous.
6. Si ProxyEndpoint est configuré pour accepter les requêtes sur default VirtualHost, passez à la cause suivante : Chemin d'accès non associé à un proxy d'API.

Solution

1. Ajoutez le VirtualHost manquant à la configuration ProxyEndpoint pour résoudre le problème. Pour l'exemple ci-dessus, vous pouvez ajouter le VirtualHost par défaut à la configuration ProxyEndpoint comme suit :

   <VirtualHost>default</VirtualHost>

   Exemple de configuration de point de terminaison de proxy montrant l'ajout de l'hôte virtuel par défaut

   

2. Dans l'exemple mentionné ci-dessus, si vous souhaitez utiliser uniquement le secure VirtualHost pour ce proxy d'API spécifique, envoyez les requêtes d'API uniquement au secure VirtualHost à l'aide du protocole HTTPS :

   https://myorg-prod.apigee.net/weather

Cause : Hôte virtuel supprimé dans une révision de proxy d'API nouvellement déployée

Ce problème peut se produire si une nouvelle révision d'un proxy d'API est déployée après la suppression d'un hôte virtuel spécifique (qui faisait partie de la révision précédemment déployée) et que les clients l'utilisent toujours pour envoyer des requêtes d'API.

Diagnostic

1. Vérifiez la configuration du point de terminaison du proxy pour le proxy d'API afin de voir si le proxy d'API est configuré pour accepter les requêtes pour l'hôte virtuel spécifié dans l'erreur. Cela est indiqué par l'élément VirtualHost dans la configuration ProxyEndpoint.
2. Si l'hôte virtuel spécifié dans l'erreur n'existe pas dans la configuration ProxyEndpoint, procédez comme suit. Dans le cas contraire, passez à la cause suivante : Chemin non associé à un proxy d'API.
3. Comparez la configuration ProxyEndpoint de la révision précédemment déployée à celle de la révision actuellement déployée.
   1. Par exemple, supposons que votre révision précédemment déployée était 5 et que votre révision actuellement déployée est 6 :
      • Hôtes virtuels configurés dans le point de terminaison du proxy de la révision 5

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>vh1</VirtualHost>
      </HTTPProxyConnection>

      • Hôtes virtuels configurés dans le point de terminaison du proxy de la révision 6

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>secure</VirtualHost>
      </HTTPProxyConnection>

   2. Dans l'exemple ci-dessus, VirtualHost vh1 existait dans revision 5,, mais a été supprimé dans revision 6 et remplacé par VirtualHost secure.
   3. Par conséquent, si vous ou vos clients envoyez des requêtes à ce proxy d'API à l'aide de VirtualHost vh1 (qui faisait partie de revision 5), vous recevrez le code de réponse 404 avec le message d'erreur suivant :

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

4. Vérifiez si la modification de l'hôte virtuel a été effectuée intentionnellement ou involontairement dans la révision actuellement déployée, puis prenez les mesures appropriées, comme expliqué dans la section Résolution.

Solution

Si vous constatez que le ou les hôtes virtuels sont supprimés dans une nouvelle révision, cela peut être intentionnel ou accidentel. Pour chaque cas, suivez les étapes de résolution/recommandées ci-dessous pour résoudre le problème.

Scénario 1 : Modification intentionnelle

Si la suppression de l'hôte virtuel est intentionnelle, vous pouvez choisir l'une des options suivantes (la première étant l'approche recommandée) :

1. Créez un proxy avec un chemin de base différent et utilisez un hôte virtuel différent (qui n'existe pas dans la révision déployée précédemment).

2. Si vous souhaitez continuer à utiliser le proxy d'API existant, mais avec un autre hôte virtuel, il est préférable de conserver l'hôte virtuel existant et d'ajouter l'hôte virtuel supplémentaire.

   Les utilisateurs de ce proxy d'API ne seront ainsi pas affectés par la modification.

3. Si vous souhaitez utiliser le proxy d'API existant et n'avoir qu'un hôte virtuel différent, informez vos utilisateurs à l'avance et effectuez cette modification pendant une période de maintenance.

   Cela permettra aux utilisateurs de ce proxy d'API d'être informés de la modification et de pouvoir utiliser un autre hôte virtuel pour effectuer les appels à ce proxy d'API. Par conséquent, ils ne seront pas affectés par le changement.

Scénario 2 : Modification involontaire

Si vous avez supprimé l'hôte virtuel par erreur et non intentionnellement,procédez comme suit :

1. Mettez à jour la configuration ProxyEndpoint dans la révision actuellement déployée pour utiliser les mêmes hôtes virtuels que ceux utilisés dans la révision déployée précédemment. Dans l'exemple ci-dessus, remplacez la section suivante :

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>secure</VirtualHost>
   </HTTPProxyConnection>

   pour

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>vh1</VirtualHost>
   </HTTPProxyConnection>

2. Redéployez la révision.

Bonnes pratiques

Il est toujours conseillé de déployer de nouveaux proxys ou de nouvelles révisions pendant une période de maintenance ou lorsque le trafic est le plus faible possible. Vous pourrez ainsi éviter tout problème survenant lors du déploiement ou minimiser l'effet sur le trafic.

Cause : Chemin d'accès non associé à un proxy d'API

Si le proxy d'API n'est pas configuré pour accepter les requêtes pour le chemin spécifique utilisé dans l'URL de la requête d'API, nous pouvons obtenir une réponse 404 Not Found avec le message d'erreur Unable to identify proxy for host: VIRTUAL_HOST and url: PATH..

Diagnostic

1. Examinez la configuration ProxyEndpoint du proxy d'API spécifique pour lequel vous prévoyiez d'effectuer les requêtes d'API.
2. Vérifiez si le proxy d'API est configuré pour accepter les requêtes pour le chemin d'accès spécifique indiqué dans le message d'erreur. Pour ce faire, suivez les étapes décrites dans les scénarios 1 et 2.

Scénario 1 : Le chemin ne correspond pas au chemin de base du proxy d'API

1. Si le path indiqué dans le message d'erreur n'est pas le même que le basepath du proxy d'API spécifique ou s'il ne commence pas par le basepath, cela peut être la cause de l'erreur.
2. Prenons un exemple pour illustrer cela :
1. Le basepath du proxy d'API prévu est /weather
2. L'URL de la requête API est https://myorg-prod.apigee.net/climate. Cela signifie que le chemin d'accès utilisé dans l'URL de la requête API est /climate..
3. Dans cet exemple, le path n'est pas identique au basepath et ne commence pas par le basepath. Par conséquent, vous obtenez l'erreur suivante :

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

Solution

1. Assurez-vous que le path utilisé dans l'URL de votre requête API est identique au basepath du proxy d'API spécifique.
2. Dans l'exemple ci-dessus, l'URL de la requête API doit être la suivante :

   {
   https://myorg-prod.apigee.net/weather

Scénario 2 : Le chemin ne correspond à aucun des flux conditionnels disponibles

1. Si le path utilisé dans l'URL de la requête API commence par basepath, il est possible que le path suffix (la partie qui suit basepath) indiqué dans le message d'erreur ne corresponde à aucun des flux conditionnels, ce qui peut entraîner l'erreur 404.
2. Prenons un exemple pour illustrer cela :
   1. Le basepath du proxy d'API prévu est /weather
   2. L'URL de la requête API est https://myorg-prod.apigee.net/weather/Delhi. Cela signifie que le chemin d'accès utilisé dans l'URL de la requête API est /weather/Delhi..
3. Dans cet exemple, le path commence par le basepath /weather. Il comporte également un path suffix de /Delhi.
4. Vérifiez maintenant s'il existe des flux conditionnels dans ProxyEndpoint.
5. S'il n'y a pas de flux conditionnels ou s'il y a quelques flux non conditionnels, passez à la cause suivante : Proxy d'API non déployé dans un environnement.
6. Si le ProxyEndpoint ne comporte que des flux conditionnels, vérifiez les points suivants :
   1. Si les conditions de tous ces flux conditionnels vérifient un proxy.pathsuffix spécifique (le chemin après le chemin de base).
   2. Si le path suffix spécifié dans l'URL de la requête API ne correspond à aucune des conditions, il s'agit de la cause de l'erreur.
7. Supposons que nous ayons deux flux dans ProxyEndpoint et qu'ils soient tous les deux des flux conditionnels, comme indiqué ci-dessous :

   <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>
   
   <Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>

   1. Dans l'exemple ci-dessus, nous avons deux flux conditionnels : l'un correspond à proxy.pathsuffix (chemin après le chemin de base) à /Bangalore et l'autre correspond à /Chennai. Mais aucune ne correspond à /Delhi, qui est le path suffix transmis dans l'URL de la requête API.
   2. Il s'agit de la cause de l'erreur 404. Par conséquent, vous obtenez l'erreur suivante :

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

Solution

1. Assurez-vous que path suffix correspond à au moins l'un des flux conditionnels de votre point de terminaison de proxy.
2. Dans l'exemple ci-dessus, vous pouvez utiliser l'une des approches suivantes pour résoudre l'erreur :
   1. Si vous souhaitez exécuter un ensemble spécifique de règles pour le chemin d'accès /Delhi, ajoutez un flux distinct avec l'ensemble de règles requis et assurez-vous qu'il existe une condition qui correspond à /proxy.pathsuffix /Delhi, comme indiqué ci-dessous :

      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>

   2. Si vous souhaitez exécuter un ensemble de règles commun pour le chemin d'accès /Delhi, assurez-vous qu'il existe une condition dans le flux commun qui autorise un /proxy.pathsuffix générique. Autrement dit, il autoriserait n'importe quel chemin après basepath /weather, comme indiqué ci-dessous :

      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

Si ProxyEndpoint comporte le basepath et le path suffix corrects spécifiés dans l'URL de l'API et qu'ils correspondent à l'un des flux conditionnels, passez à la cause suivante : Proxy d'API non déployé dans un environnement.

Cause : Proxy d'API non déployé dans un environnement

Diagnostic

1. Déterminez l'environnement auquel appartient l'alias d'hôte utilisé dans l'URL de votre requête API. Pour ce faire, vérifiez les détails de tous les hôtes virtuels dans chacun des environnements de votre organisation dans l'interface utilisateur Edge.

   Par exemple, supposons la configuration suivante :

   • Si http://myorg-prod.apigee.net/weather est votre URL, myorg-prod.apigee.net est l'alias d'hôte.
   • L'alias d'hôte myorg-prod.apigee.net est configuré dans l'un des hôtes virtuels de l'environnement prod de votre organisation.
2. Vérifiez si le proxy d'API spécifique est déployé dans l'environnement spécifique déterminé à l'étape 1 ci-dessus.
3. Si le proxy d'API n'est pas déployé dans l'environnement spécifique, il s'agit de la cause de l'erreur 404.
   1. Ainsi, dans l'exemple utilisé à l'étape 1 ci-dessus, supposons que le proxy d'API ne soit pas déployé dans l'environnement prod. Il s'agit alors de la cause de l'erreur.
   2. Consultez la section Résolution ci-dessous.
4. Si le proxy d'API est déployé dans l'environnement spécifique, passez à la cause suivante : Environnement non chargé sur les processeurs de messages.

Solution

Déployez le proxy d'API dans l'environnement spécifique dans lequel vous prévoyez d'envoyer des requêtes API.

Cause : l'environnement n'est pas chargé sur les processeurs de messages.

Diagnostic

1. Connectez-vous à chacun des processeurs de messages et vérifiez si l'environnement spécifique dans lequel vous effectuez la requête d'API est chargé sur le processeur de messages à l'aide de la commande suivante :

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

2. Si l'environnement spécifique est répertorié dans la commande ci-dessus, passez à la cause suivante : Proxy d'API non déployé sur un ou plusieurs processeurs de messages.
3. Si l'environnement spécifique n'est pas listé, vérifiez /opt/apigee/var/log/edge-message-processor/logs/system.log et /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log sur les processeurs de message pour détecter les éventuelles erreurs lors du chargement des environnements.
4. Plusieurs erreurs peuvent entraîner l'échec du chargement d'un environnement sur le processeur de messages. La résolution dépend de l'erreur qui s'est produite.

Solution

L'environnement peut ne pas être chargé sur le processeur de messages pour de nombreuses raisons. Cette section présente quelques raisons possibles de ce problème et explique comment le résoudre.

1. Si l'une des erreurs suivantes s'affiche dans le journal du processeur de messages, cela est dû à un problème détecté avec les certificats/clés qui ont été ajoutés au keystore/truststore spécifié dans l'environnement spécifié.

   Erreur 1 : java.security.KeyStoreException : Impossible d'écraser son propre certificat

   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

   Erreur 2 : java.security.KeyStoreException : impossible d'écraser la clé secrète

   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. Obtenez les détails du keystore/truststore spécifié dans le message d'erreur affiché à l'étape précédente en utilisant l'appel d'API de gestion suivant :

   curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user> 

   
   

   Exemple de résultat :

   {
      "certs":[
         "mycert",
         "mycert-new"
      ],
      "keys":[
         "mycert"
      ],
      "name":"myTruststore"
   }

3. L'exemple de résultat montre qu'il existe deux certificats et une clé dans le truststore myTruststore. Le truststore ne contient généralement pas de clé. Si c'est le cas, il est préférable d'avoir un seul certificat et une seule clé.
4. Obtenez des informations sur les deux certificats à l'aide de l'API suivante :

   curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
   

5. Vérifiez la date d'expiration de chacun des certificats et identifiez celui qui a expiré ou qui est le plus ancien.
6. Supprimez le certificat expiré ou indésirable du truststore myTruststore.

Si le problème persiste ou si vous rencontrez une erreur autre que celles mentionnées à l'étape 1 ci-dessus, consultez la page Vous devez collecter des informations de diagnostic.

Cause : le proxy d'API n'est pas déployé sur un ou plusieurs processeurs de messages.

Il est possible que le proxy d'API ne soit pas déployé sur un ou plusieurs processeurs de messages. Ce problème se produit très rarement, principalement en raison d'une notification d'événement manquante du serveur de gestion au processeur de message lors du déploiement du proxy d'API spécifique. Dans ce cas également, vous ne pourrez pas créer la session de trace dans l'interface utilisateur Edge.

Diagnostic

1. Connectez-vous à chacun des processeurs de messages et vérifiez si la révision spécifique du proxy d'API est déployée ou non à l'aide de la commande suivante :

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
   

2. Si la révision spécifique du proxy d'API ne s'affiche pas dans le résultat de la commande mentionnée à l'étape 1 ci-dessus, redémarrez le processeur de messages spécifique, comme expliqué dans la section Résolution.
3. Répétez les étapes 1 et 2 pour tous les processeurs de messages.
4. Si la révision spécifique du proxy d'API est déployée sur tous les processeurs de messages, ce n'est pas la cause de ce problème. Consultez la page Vous devez collecter des informations de diagnostic.

Solution

Redémarrez les processeurs de messages spécifiques sur lesquels la révision spécifique du proxy d'API n'est pas déployée.

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

Diagnostiquer les problèmes à l'aide de la surveillance des API

API Monitoring vous permet d'isoler rapidement les zones à problèmes pour diagnostiquer les problèmes d'erreur, de performances et de latence, ainsi que leur source, comme les applications de développeur, les proxys d'API, les cibles de backend ou la plate-forme d'API.

Pour ce problème, vous pouvez accéder à la page Surveillance des API > Examiner, choisir la date, le proxy, etc. appropriés, et afficher les informations suivantes :

• Code d'erreur : messaging.adaptors.http.flow.ApplicationNotFound
• Code d'état : 404
• Source de la défaillance : Apigee ou MP

Vous pouvez également cliquer sur Afficher les journaux, comme indiqué dans la capture d'écran ci-dessus, pour en savoir plus.

La section Parcourir un exemple de scénario montre comment résoudre les problèmes 5xx liés à vos API à l'aide d'API Monitoring. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le nombre de codes d'état 404 dépasse un seuil particulier.

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes. Contactez l'assistance Apigee Edge et partagez ces informations avec elle.

1. Si vous êtes un utilisateur du cloud public, fournissez les informations suivantes :
   • Nom de l'organisation
   • Nom de l'environnement
   • Nom de proxy d'API
   • Commande curl complète pour reproduire l'erreur
2. Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :
   • Message d'erreur complet observé
   • Nom de l'environnement
   • Bundle de proxy d'API
   • Journaux du processeur de messages /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Résultat des commandes suivantes sur chacun des processeurs de messages.

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
         

3. Détails sur les sections de ce guide que vous avez essayées et toute autre information qui nous aidera à résoudre ce problème rapidement.