Cette page a été traduite par l'API Cloud Translation.

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

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'application cliente reçoit le 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 que Edge n'a pas pu trouver le proxy d'API pour l'hôte virtuel et le chemin d'accès spécifiés.

Message d'erreur

Le code d'état HTTP suivant s'affiche:

HTTP/1.1 404 Not Found

Un message d'erreur semblable à celui présenté ci-dessous s'affiche é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 que Edge n'a pas pu trouver le proxy d'API pour le Hôte virtuel default et chemin d'accès /oauth2/token

Causes possibles :

Voici quelques-unes des causes possibles de cette erreur:

Cause	Description	Instructions de dépannage applicables
<ph type="x-smartling-placeholder"></ph> Proxy d'API non associé à l'hôte virtuel spécifique	Le proxy d'API spécifique n'est pas configuré pour accepter les requêtes sur l'hôte virtuel spécifié dans le message d'erreur.	Utilisateurs Edge de cloud public et privé
Hôte virtuel supprimé dans une révision récemment déployée du proxy d'API	Supprimer l'hôte virtuel de la révision récemment déployée pendant que le client est toujours l'utilisation de l'hôte virtuel spécifique peut causer ce problème.	Utilisateurs Edge de cloud public et privé
<ph type="x-smartling-placeholder"></ph> Chemin d'accès non associé à un proxy d'API	Le proxy d'API spécifique n'est pas configuré pour accepter les requêtes sur le chemin spécifié. dans le message d'erreur.	Utilisateurs Edge de cloud public et privé
<ph type="x-smartling-placeholder"></ph> Proxy d'API non déployé dans un environnement	Le proxy d'API spécifique n'est pas déployé dans l'environnement spécifique dans lequel vous les requêtes API.	Utilisateurs Edge de cloud public et privé
<ph type="x-smartling-placeholder"></ph> Environnement non chargé sur le processeur de messages	L'environnement spécifique (dans lequel vous essayez d'effectuer les requêtes API) n'a pas été chargé sur les processeurs de messages en raison d'une erreur.	Utilisateurs de cloud privé Edge
<ph type="x-smartling-placeholder"></ph> Proxy d'API non déployé sur un ou plusieurs processeurs de messages	Le proxy d'API peut ne pas être déployé sur un ou plusieurs processeurs de messages en raison de une notification d'événement pendant le déploiement.	Utilisateurs de cloud privé Edge

Étapes de diagnostic courantes

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

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

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

Vérifiez 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 à partir des journaux.

Vérifier les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) pour voir si vous avez messaging.adaptors.http.flow.ApplicationNotFound pour l'API spécifique ou, si vous disposez de l'étape 2 pour la requête 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 affiche le code et le message d'erreur suivants:

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

Remarque:Les champs url et host ci-dessus peuvent varier en fonction du proxy d'API. pour laquelle vous rencontrez le problème.

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 de l'hôte virtuel spécifique, alors 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

Vérifiez la configuration du point de terminaison du proxy pour le proxy d'API et voyez si le proxy d'API est configuré pour accepter les requêtes de l'hôte virtuel spécifié dans l'erreur. C'est indiquée par l'élément VirtualHost. Examinons un exemple de ProxyEndpoint configuration pour comprendre cela.
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é

Imaginons 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`

Vous envoyez une requête API au VirtualHost default à l'aide de l'URL http://myorg-prod.apigee.net/weather
Comme ProxyEndpoint ne comporte pas de VirtualHost default, comme indiqué dans le dans 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"}}}
```
Accédez à la section Résolution ci-dessous pour résoudre ce problème.
Si ProxyEndpoint est configuré pour accepter les requêtes sur le default VirtualHost, passez à la cause suivante <ph type="x-smartling-placeholder"></ph> Chemin d'accès non associé à un proxy d'API.

Solution

Ajoutez le VirtualHost manquant à la configuration ProxyEndpoint pour résoudre le problème. Pour l'exemple ci-dessus, vous pouvez ajouter la valeur par défaut VirtualHost à la configuration ProxyEndpoint, comme suit:
```
<VirtualHost>default</VirtualHost>
```
Exemple de configuration du point de terminaison du proxy affichant la valeur par défaut> VirtualHost> en cours d'ajout
Dans l'exemple mentionné ci-dessus, si vous aviez l'intention d'utiliser uniquement secure VirtualHost pour ce proxy d'API spécifique, puis effectuer les requêtes API uniquement vers secure VirtualHost à l'aide du protocole HTTPS:
```
https://myorg-prod.apigee.net/weather
```

Cause: hôte virtuel supprimé dans une révision récemment déployée du proxy API

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), qui est toujours utilisée par les clients pour effectuer des requêtes API, cela peut être à l'origine du problème.

Diagnostic

Vérifiez la configuration du point de terminaison du proxy pour le proxy d'API pour voir si le proxy d'API est configuré pour accepter les requêtes de l'hôte virtuel spécifié dans l'erreur. C'est indiquée par l'élément VirtualHost dans la configuration ProxyEndpoint.
Si l'hôte virtuel spécifié dans l'erreur n'existe pas dans ProxyEndpoint , puis effectuez les étapes suivantes. Sinon, passez à la cause suivante : Chemin d'accès non associé à un proxy d'API.
Comparez la configuration ProxyEndpoint de la révision précédemment déployée avec la version actuelle la révision déployée.
1. Par exemple, supposons que la révision précédemment déployée soit 5 et que votre la révision actuellement déployée est 6: <ph type="x-smartling-placeholder">
  - Hôtes virtuels configurés dans le point de terminaison du proxy dans la révision 5
  - Hôtes virtuels configurés dans le point de terminaison du proxy dans la révision 6
2. Dans l'exemple ci-dessus, VirtualHost vh1 existait dans revision 5,. mais est supprimée dans revision 6 et remplacée par VirtualHost secure.
3. 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 obtiendrez 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"}}}
```
Vérifiez si l'hôte virtuel a été modifié intentionnellement ou de manière involontaire dans la révision déployée et les mesures appropriées, comme expliqué dans la section Résolution.

Solution

Si vous constatez que l'hôte ou les hôtes virtuels ont été supprimés dans une nouvelle révision, cela peut être intentionnel ou accidentel. Pour chaque cas, suivez la procédure recommandée ou la procédure de résolution suivante pour résoudre le problème.

Scénario 1: Changement intentionnel

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

Créer un proxy avec un chemin de base différent et utiliser un hôte virtuel différent (qui n'existe pas dans la révision déployée précédemment).
Si vous souhaitez continuer à utiliser le proxy d'API existant mais avec un hôte virtuel différent, il est préférable de conserver l'hôte virtuel existant et d'ajouter l'hôte virtuel supplémentaire.

Cela garantira que les utilisateurs de ce proxy d'API ne seront pas affectés par la modification.
Si vous souhaitez utiliser le proxy d'API existant et que vous n'avez qu'un hôte virtuel différent, alors informer vos utilisateurs à l'avance et effectuer cette modification pendant une période de maintenance.

Les utilisateurs de ce proxy d'API seront ainsi informés du changement et peuvent utiliser un hôte virtuel différent pour effectuer les appels vers ce proxy d'API. Par conséquent, ils ne seront pas affectées par ce changement.

Scénario 2: changement involontaire

Si la suppression de l'hôte virtuel est effectuée par erreur et non intentionnelle,procédez comme suit:

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 précédemment déployée. Dans 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>

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 quand le trafic est le moins attendu, de sorte que tout problème survenant lors du déploiement ou l'impact sur le trafic peut être évité.

Cause: le chemin d'accès n'est associé à aucun proxy d'API

Si le proxy d'API n'est pas configuré pour accepter les requêtes pour le chemin spécifique utilisé dans le l'URL de requête de l'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

Examinez la configuration ProxyEndpoint du proxy d'API spécifique que vous souhaitiez utiliser. pour envoyer les requêtes API.
Vérifier si le proxy d'API est configuré pour accepter les requêtes pour le chemin spécifique indiqué dans le message d'erreur. Pour ce faire, suivez les étapes décrites dans Scénario 1 et Scénario 2 :

Scénario 1: le chemin d'accès ne correspond pas au chemin de base du proxy d'API

Si la path indiquée dans le message d'erreur est différente de basepath du proxy d'API spécifique ou s'il ne commence pas par basepath, alors ce peut être la cause de l'erreur.
Prenons un exemple pour expliquer cela:

Le basepath du proxy d'API prévu est /weather
L'URL de requête de l'API est https://myorg-prod.apigee.net/climate. Cela signifie que le chemin utilisé dans l'URL de la requête API est /climate.

Dans cet exemple, path est différent de basepath. ne pas commencer par basepath. Vous obtenez donc l'erreur suivante:

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

Solution

Vérifiez que le path utilisé dans l'URL de votre requête API est identique à basepath du proxy d'API spécifique.
Dans l'exemple ci-dessus, l'URL de requête API doit se présenter comme suit:
```
{
https://myorg-prod.apigee.net/weather
```

Scénario 2: Le chemin d'accès ne correspond à aucun des flux conditionnels disponibles

Si le path utilisé dans l'URL de requête de l'API commence par basepath, il est alors possible que path suffix (la partie qui suit la commande basepath) indiquée dans le message d'erreur ne correspond à aucune des conditions cela peut entraîner l'erreur 404.
Prenons un exemple pour expliquer cela: <ph type="x-smartling-placeholder">
1. Le basepath du proxy d'API prévu est /weather
2. L'URL de requête de l'API est https://myorg-prod.apigee.net/weather/Delhi. Cela signifie le chemin utilisé dans l'URL de la requête API est /weather/Delhi.
Dans cet exemple, path commence par basepath /weather. De plus, son path suffix est de /Delhi.
Vérifiez maintenant s'il existe des flux conditionnels dans ProxyEndpoint.
S'il n'y a pas de flux conditionnels ou non conditionnels, accédez à cause suivante - Proxy d'API non déployé dans un environnement
Si ProxyEndpoint ne comporte que des flux conditionnels, vérifiez les points suivants: <ph type="x-smartling-placeholder">
1. Si les conditions de tous ces flux conditionnels recherchent un proxy.pathsuffix spécifique (le chemin d'accès après le chemin de base).
2. Si l'path suffix spécifié dans l'URL de requête de l'API ne correspond à aucune des alors c'est la cause de l'erreur.
Supposons que nous ayons deux flux dans ProxyEndpoint et qu'ils soient tous les deux 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>
```
<ph type="x-smartling-placeholder">
1. Dans l'exemple présenté ci-dessus, nous avons deux flux conditionnels, l'un qui correspond proxy.pathsuffix (chemin d'accès après le chemin de base) vers /Bangalore et le l'autre correspond à /Chennai. Mais aucune ne correspond à /Delhi qui correspond au path suffix transmis dans l'URL de requête de l'API.
2. C'est la cause de l'erreur 404. Vous obtenez donc l'erreur suivante:
```
{
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}
```

Solution

Assurez-vous que path suffix correspond à au moins l'un des flux conditionnels de votre point de terminaison de proxy.
Dans l'exemple ci-dessus, vous pouvez utiliser les approches suivantes pour résoudre l'erreur: <ph type="x-smartling-placeholder">
1. Si vous souhaitez exécuter un ensemble spécifique de stratégies pour le chemin /Delhi, puis 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 commun de stratégies pour le chemin /Delhi, alors dans le flux commun, assurez-vous qu'il existe une condition qui permette /proxy.pathsuffix Autrement dit, tout chemin d'accès après basepath est autorisé. /weather comme indiqué ci-dessous:
```
<Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>
```

Si ProxyEndpoint comporte la bonne valeur basepath et la valeur de path suffix spécifiée dans l'URL de l'API correspond à l'un des flux conditionnels, on passe à la cause suivante : Proxy d'API non déployé dans un environnement.

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

Diagnostic

Déterminez l'environnement dans lequel existe l'alias d'hôte utilisé dans votre URL de requête API. Pour ce faire, vous pouvez vérifier 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 correspond à votre URL, alors myorg-prod.apigee.net est l'alias de l'hôte.
- L'alias d'hôte myorg-prod.apigee.net est configuré dans l'un des des hôtes virtuels dans l'environnement prod de votre organisation.
Vérifiez si le proxy d'API spécifique est déployé dans l'environnement spécifique déterminé dans l'étape 1 ci-dessus.
Si le proxy d'API n'est pas déployé dans l'environnement spécifique, cela est la cause du problème l'erreur 404.
1. Ainsi, dans l'exemple utilisé à l'étape 1 ci-dessus, supposons que le proxy d'API n'est pas déployé dans le prod, c'est la cause de l'erreur.
2. Passez à la section Résolution ci-dessous.
Si le proxy d'API est déployé dans l'environnement spécifique, passez à la cause suivante - <ph type="x-smartling-placeholder"></ph> Environnement non chargé sur les processeurs de messages

Solution

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

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

Diagnostic

Connectez-vous à chacun des processeurs de messages et vérifiez si l'environnement spécifique dans lequel vous effectuent la requête API est chargée sur le processeur de messages à l'aide de la commande suivante:
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
```
Si l'environnement spécifique est indiqué dans la commande ci-dessus, passez à la cause suivante : <ph type="x-smartling-placeholder"></ph> Proxy d'API non déployé sur un ou plusieurs processeurs de messages
Si l'environnement spécifique ne figure pas dans la liste, vérifiez /opt/apigee/var/log/edge-message-processor/logs/system.log et /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log le des processeurs de messages en cas d'erreur lors du chargement des environnements.
De nombreuses erreurs différentes 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

Il est possible que l'environnement ne soit pas chargé sur le processeur de messages pour de nombreuses raisons. Cette section illustre quelques raisons pouvant expliquer ce problème et explique comment le résoudre. le problème.

Si l'une des erreurs suivantes apparaît dans le journal du processeur de messages, elle est due à une erreur 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 n° 1: java.security.KeyStoreException: Impossible de remplacer votre 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 n° 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

Obtenez les détails du keystore/truststore spécifié dans le message d'erreur affiché dans la à l'étape précédente à l'aide de 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"
}

L'exemple de résultat montre qu'il y a 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 mieux vaut avoir un seul certificat et une seule clé.

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>

Vérifiez la date d'expiration de chacun des certificats et déterminez s'il est arrivé à expiration ou plus ancien.
Supprimez le certificat expiré ou indésirable du truststore myTruststore.

Si le problème persiste ou si vous voyez apparaître une autre erreur que celles mentionnées à l'étape 1 ci-dessus, consultez Collecte des informations de diagnostic requise.

Cause: proxy d'API non déployé sur un ou plusieurs processeurs de messages

Le proxy d'API ne peut pas être déployé sur un ou plusieurs processeurs de messages. Ce problème survient rarement et se produit principalement en raison d'une notification d'événement manquante du serveur de gestion pour Processeur de messages pendant le déploiement du proxy d'API spécifique. Dans ce cas également, vous ne pourra pas créer la session de trace dans l'interface utilisateur Edge.

Diagnostic

Connectez-vous à chacun des processeurs de messages et vérifiez si la révision spécifique du Le proxy d'API est déployé ou non à l'aide de la commande suivante:
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
```
Si la révision spécifique du proxy d'API n'apparaît pas dans la sortie de la commande mentionnée à l'étape 1 ci-dessus, puis redémarrez le processeur de messages spécifique, comme expliqué dans Résolution.
Répétez les étapes 1 et 2 pour tous les processeurs de messages.
Si la révision spécifique du proxy d'API est déployée sur tous les processeurs de messages, alors ce n'est pas la cause de ce problème. Accéder à <ph type="x-smartling-placeholder"></ph> doit recueillir des informations de diagnostic.

Solution

Redémarrer les processeurs de messages spécifiques sur lesquels la révision spécifique du proxy d'API est non déployées.

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

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

La surveillance des API vous permet d'isoler rapidement les zones problématiques. pour diagnostiquer les problèmes d'erreurs, de performances et de latence, ainsi que leur source, comme les applications de développement, Les proxys d'API, les cibles backend ou la plate-forme d'API.

Pour ce problème, vous pouvez accéder à la page Surveillance des API > Examiner et choisissez la date, la date et l'heure appropriées, etc. Les informations suivantes peuvent s'afficher:

Code d'erreur et code d'état dans l'interface utilisateur

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

De plus, vous pouvez cliquer sur View logs (Afficher les journaux) comme illustré dans la capture d'écran ci-dessus et vérifier.

afficher les journaux

Consultez un exemple de scénario pour savoir comment : Résolvez les problèmes 5xx de vos API à l'aide de la surveillance des API. Par exemple, vous pouvez Vous souhaitez configurer une alerte pour être averti lorsque le nombre de codes d'état 404 dépasse une un seuil particulier.

Vous devez collecter des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, rassemblez les à l'aide des informations de diagnostic suivantes. Contactez l'assistance Apigee Edge et partagez-la.

Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes: <ph type="x-smartling-placeholder">
- Nom de l'organisation
- Nom de l'environnement
- Nom de proxy d'API
- Exécutez la commande curl pour reproduire l'erreur
Si vous êtes un utilisateur de Private Cloud, fournissez les informations suivantes: <ph type="x-smartling-placeholder">
- Message d'erreur complet observé
- Nom de l'environnement
- Groupe de proxys 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.
Des détails sur les sections de ce playbook que vous avez essayées et toute autre information qui nous aidera à accélérer la résolution de ce problème.