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>

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Problème constaté

L'application cliente obtient 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 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

Vous obtiendrez le code d'état HTTP suivant:

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 l'hôte virtuel default et le chemin /oauth2/token.

Causes possibles :

Voici quelques-unes des causes possibles de cette erreur:

Cause	Description	Instructions de dépannage applicables
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 Public and Private Cloud
Hôte virtuel supprimé dans une révision nouvellement déployée du proxy d'API	Ce problème peut être dû à la suppression de l'hôte virtuel de la révision nouvellement déployée alors que le client utilise toujours l'hôte virtuel spécifique.	Utilisateurs Edge Public and Private Cloud
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 d'accès spécifié dans le message d'erreur.	Utilisateurs Edge Public and Private Cloud
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 essayez d'envoyer les requêtes API.	Utilisateurs Edge Public and Private Cloud
Environnement non chargé sur le processeur de messages	L'environnement spécifique (dans lequel vous essayez d'envoyer les requêtes API) n'a pas été chargé sur les processeurs de messages en raison d'une erreur.	Utilisateurs de cloud privé périphérique
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 en raison de l'absence de notification d'événement lors du déploiement.	Utilisateurs de cloud privé périphérique

É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:

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 dans les journaux.

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 disposez de l'ID de message unique 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 d'erreur et le message d'erreur comme suit:

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

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

Cause: proxy d'API non 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

Vérifiez la configuration du point de terminaison du proxy pour le proxy d'API et assurez-vous que celui-ci 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. Examinons un exemple de configuration de ProxyEndpoint pour comprendre cela.
Exemple de configuration du point de terminaison du proxy montrant que le proxy d'API accepte les requêtes sur un hôte virtuel sécurisé

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`

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

Résolution

Ajoutez l'élément VirtualHost manquant à la configuration ProxyEndpoint pour résoudre le problème. Pour l'exemple ci-dessus, vous pouvez ajouter l'élément VirtualHost par défaut à la configuration ProxyEndpoint comme suit :
```
<VirtualHost>default</VirtualHost>
```
Exemple de configuration du point de terminaison du proxy montrant l'ajout par défaut de VirtualHost
Sinon, dans l'exemple ci-dessus, si vous avez l'intention d'utiliser uniquement le VirtualHost secure pour ce proxy d'API spécifique, vous pouvez envoyer les requêtes API uniquement au VirtualHost secure à l'aide du protocole HTTPS :
```
https://myorg-prod.apigee.net/weather
```

Cause: hôte virtuel supprimé dans une révision nouvellement déployée du proxy d'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é par les clients pour effectuer des requêtes API, ce problème peut alors être à l'origine de ce problème.

Diagnostic

Vérifiez la configuration du point de terminaison du proxy pour le proxy d'API afin de savoir si celui-ci 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.
Si l'hôte virtuel spécifié dans l'erreur n'existe pas dans la configuration ProxyEndpoint, procédez comme suit. 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 révision actuellement déployée.
1. Par exemple, supposons que la révision précédemment déployée soit 5 et que la révision actuellement déployée soit 6 :
  - 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 a été supprimé dans revision 6 et remplacé par VirtualHost secure.
3. Ainsi, 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 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"}}}
```
Vérifiez si la modification de l'hôte virtuel a été effectuée intentionnellement ou non intentionnelle dans la révision actuellement déployée et prenez les mesures appropriées, comme expliqué dans la section Résolution.

Résolution

Si vous constatez que le 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 de résolution/recommandée ci-dessous afin de 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, la première étant l'approche recommandée:

Créez un proxy avec un chemin de base différent et utilisez un autre hôte virtuel (qui n'existe pas dans la révision précédemment déployée).
Si vous souhaitez continuer à utiliser le proxy API existant, mais utiliser 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 cette modification.
Si vous souhaitez utiliser le proxy d'API existant et ne disposez que d'un hôte virtuel différent, informez-en vos utilisateurs et effectuez cette modification pendant une période de maintenance.

Cela permettra de s'assurer que les utilisateurs de ce proxy d'API sont au courant de la modification et qu'ils peuvent utiliser un autre hôte virtuel pour effectuer les appels à ce proxy d'API. Ils ne seront donc pas concernés par ce changement.

Scénario 2: Changement involontaire

Si la suppression de l'hôte virtuel est effectuée par erreur et non intentionnellement,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 de la révision précédemment déployée. Dans l'exemple ci-dessus, remplacez la section suivante par :

<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 lorsque le trafic est le moins attendu, afin d'éviter tout problème survenant lors du déploiement ou de minimiser les effets 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 requête 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 pour lequel vous souhaitiez envoyer les requêtes API.
Vérifiez 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 du scénario 1 et du scénario 2.

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

Si le path indiqué dans le message d'erreur n'est pas identique au basepath du proxy d'API spécifique ou s'il ne commence pas par basepath, cela 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 la requête 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 n'est pas identique à basepath et ne commence pas par 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"
      }
   }
}

Résolution

Assurez-vous que le path utilisé dans l'URL de votre requête API est identique au 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 ne correspond à aucun des flux conditionnels disponibles

Si l'élément path utilisé dans l'URL de requête de l'API commence par basepath, il est possible que l'élément path suffix (qui se trouve après basepath) indiqué dans le message d'erreur ne corresponde à aucun des flux conditionnels. Cela pourrait alors entraîner l'erreur 404.
Prenons un exemple pour expliquer 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 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 défini sur /Delhi.
Vérifiez maintenant si ProxyEndpoint comporte des flux conditionnels.
S'il n'y a pas de flux conditionnels ou s'il existe quelques flux non conditionnels, passez à la cause suivante : Proxy d'API non déployé dans un environnement.
Si ProxyEndpoint ne comporte que des flux conditionnels, vérifiez les éléments suivants :
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 le path suffix spécifié dans l'URL de requête API ne correspond à aucune des conditions, c'est la cause de l'erreur.
Imaginons que nous ayons deux flux dans ProxyEndpoint et qu'ils soient tous 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 qui correspond à proxy.pathsuffix (chemin d'accès après le chemin de base) à /Bangalore, et l'autre à /Chennai. Toutefois, aucune ne correspond à /Delhi, qui est l'élément path suffix transmis dans l'URL de requête API.
2. C'est 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"
      }
   }
}
```

Résolution

Assurez-vous que path suffix correspond à au moins 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 :
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'une condition correspond à la /Delhi /proxy.pathsuffix, comme indiqué ci-dessous :
```
<Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
```
2. Si vous souhaitez exécuter un ensemble commun de règles pour le chemin d'accès /Delhi, assurez-vous, dans le flux commun, qu'une condition autorise une /proxy.pathsuffix générique. Autrement dit, tous les chemins d'accès après la /weather basepath sont autorisés, comme indiqué ci-dessous :
```
<Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>
```

Si ProxyEndpoint a le bon basepath et que le path suffix spécifié dans l'URL de l'API correspond à 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

Déterminez l'environnement dans lequel existe 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.
Prenons l'exemple de 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.
Vérifiez si le proxy d'API spécifique est déployé dans l'environnement déterminé à l'étape 1 ci-dessus.
Si le proxy d'API n'est pas déployé dans l'environnement spécifique, c'est la cause de 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 l'environnement prod, c'est la cause de l'erreur.
2. Accédez à la section Résolution ci-dessous.
Si le proxy d'API est déployé dans l'environnement spécifique, passez à l'origine du problème : L'environnement n'est pas chargé sur les processeurs de messages.

Ré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

Connectez-vous à chacun des processeurs de messages et vérifiez si l'environnement spécifique dans lequel vous effectuez la requête API est chargé 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 répertorié dans la commande ci-dessus, passez à l'origine du problème : Proxy d'API non déployé sur un ou plusieurs processeurs de messages.
Si l'environnement spécifique n'est pas répertorié, vérifiez que /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 messages ne contiennent pas d'erreurs 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 survenue.

Résolution

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

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

Erreur n° 1: java.security.KeyStoreException: Cannot replace own certificate

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: Cannot override secret key

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é à 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 existe deux certificats et une clé dans le magasin de confiance myTruststore. Le Truststore ne contient généralement pas de clé. Si c'est le cas, il est préférable de disposer d'un seul certificat et d'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 identifiez le certificat arrivé à expiration/l'ancien.
Supprimez le certificat expiré ou indésirable du Trustedstore myTruststore.

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

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 se produit très rarement et se produit principalement en raison d'une notification d'événement manquante du serveur de gestion au processeur de messages 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

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
```
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, redémarrez le processeur de messages spécifique comme expliqué dans la section Résolution.
Répétez les étapes 1 à 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, ce problème n'est pas la cause de ce problème. Consultez Vous devez collecter des informations de diagnostic.

Ré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

La surveillance des API vous permet d'isoler rapidement les problèmes afin de diagnostiquer les problèmes d'erreur, de performances et de latence, ainsi que leur source. C'est le cas, par exemple, des applications pour développeurs, des proxys d'API, des cibles backend ou de la plate-forme d'API.

Pour ce problème, vous pouvez accéder à la page Surveillance des API > Analyser et choisir la date, le proxy, etc. appropriés. 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

Vous pouvez aussi cliquer sur View logs (Afficher les journaux) comme illustré dans la capture d'écran ci-dessus, pour aller plus loin.

Afficher les journaux

Suivez un exemple de scénario qui montre comment résoudre les problèmes 5xx liés à vos API à l'aide de la surveillance des API. 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 et partagez ces informations avec l'assistance Apigee Edge.

Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes :
- Le nom de l'organisation.
- Nom de l'environnement
- Nom de proxy d'API
- Exécuter la commande curl pour reproduire l'erreur
Si vous êtes un utilisateur de cloud privé, fournissez les informations suivantes :
- 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
- Générez les commandes suivantes sur chacun des processeurs de messages.
Informations sur les sections de ce playbook que vous avez essayées et sur tout autre insight qui pourrait nous aider à accélérer la résolution de ce problème.