Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

502 Passerelle incorrecte

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

Problème constaté

L'application cliente reçoit un code d'état HTTP 502 avec le message "Bad Gateway" en réponse aux appels d'API.

Le code d'état HTTP 502 signifie que le client ne reçoit pas de réponse valide des serveurs backend qui devraient normalement traiter la requête.

Messages d'erreur

L'application cliente reçoit le code de réponse suivant :

HTTP/1.1 502 Bad Gateway

Vous pouvez également observer les messages d'erreur suivants :

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Si l'erreur provient du serveur backend, vous pouvez voir quelque chose comme ceci. Le message d'erreur du backend dépend entièrement de son implémentation.

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

Causes possibles :

Voici quelques causes possibles de l'erreur 502 Bad Gateway pour les API qui transitent par Apigee Edge :

Cause	Description	Instructions de dépannage applicables à
Aucun processeur de messages disponible dans le pool	Cette erreur est observée si tous les processeurs de messages du pool ne sont pas disponibles, c'est-à-dire qu'ils sont hors service ou occupés et ne répondent donc pas.	Utilisateurs d'Edge pour le cloud privé
Configuration SSL incorrecte entre les routeurs et les processeurs de messages	Cette erreur est observée si le certificat racine signé par l'autorité de certification du client est manquant dans le truststore du routeur d'Edge.	Utilisateurs d'Edge pour le cloud privé
Erreur du serveur backend	Cette erreur est observée si le serveur backend échoue et envoie cette réponse.	Utilisateurs d'Edge pour le cloud public et privé

Cause : Aucun processeur de messages disponible dans le pool

Cette erreur se produit si le routeur constate que tous les processeurs de messages d'une région/d'un centre de données donné ne sont pas disponibles (par exemple, s'ils sont tous hors service).

Apigee Edge est configuré de sorte que le trafic API entrant (requêtes) dans une région/un centre de données donné est toujours acheminé des routeurs vers les processeurs de messages (MPs) de la même région/du même centre de données. Dans certains cas, les composants Apigee Edge peuvent être configurés dans une seule région/un seul centre de données, et dans d'autres cas, ils peuvent être configurés dans plusieurs régions/centres de données. Dans chaque région/centre de données, deux routeurs et processeurs de messages ou plus sont configurés.

Diagnostic

Déterminez la ou les régions/centres de données dans lesquels les requêtes API échouent avec l'erreur 502 Bad Gateway, s'il existe plusieurs régions/centres de données. Pour ce faire, identifiez la région dans laquelle les utilisateurs observent des erreurs 502 ou consultez les journaux d'accès NGINX dans le répertoire /opt/apigee/var/log/edge-router/nginx/ sur chacun des routeurs appartenant à différentes régions.

L'erreur suivante s'affiche dans les journaux d'erreurs NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log)

2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

Scénario 1 : Tous les processeurs de messages sont hors service

Vérifiez si les processeurs de messages de la région/du centre de données spécifique sont opérationnels.
Si tous les processeurs de messages sont hors service, redémarrez-les.

Solution

Redémarrez tous les processeurs de messages à l'aide de la commande suivante :

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

Scénario 2 : Tous les processeurs de messages sont occupés à traiter des requêtes en cours

Cette erreur se produit si les routeurs constatent que tous les processeurs de messages d'une région/d'un centre de données donné ne sont pas disponibles, car ils sont tous occupés à traiter des requêtes en cours.

Vérifiez si les processeurs de messages de la région/du centre de données spécifique sont opérationnels.
Si tous les processeurs de messages sont opérationnels et actifs, vérifiez si le ou les processeurs de messages connaissent une utilisation élevée du processeur, puis générez trois dumps de thread toutes les 30 secondes à l'aide de la commande suivante :
```
<JAVA_HOME>/bin/jstack -l <pid> > <filename>
```
Si le ou les processeurs de messages connaissent une utilisation élevée de la mémoire, générez un dump de tas à l'aide de la commande suivante :
```
sudo -u apigee /bin/jmap -dump:live,format=b,file= 
```
Redémarrez le processeur de messages à l'aide de la commande ci-dessous. Cela devrait réduire l'utilisation du processeur et de la mémoire :
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
Surveillez les appels d'API pour vérifier si le problème persiste.
Contactez l'assistance Apigee et fournissez les dumps de thread, l'empreinte de la mémoire et les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) pour vous aider à déterminer la cause de l'utilisation élevée du processeur/de la mémoire.

Cause : Configuration SSL incorrecte entre les routeurs et les processeurs de messages

Diagnostic

Consultez les journaux d'accès NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Vous verrez la réponse 502 comme indiqué ci-dessous :

    2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-

Consultez les journaux d'erreurs NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Vous verrez des erreurs comme celle-ci :

	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"

Cela indique que le handshake SSL échoue entre le routeur et le processeur de messages.
Si vous examinez attentivement le message d'erreur des étapes 1 et 2, le numéro de port utilisé pour communiquer avec le processeur de messages est 8998, qui est un port non sécurisé, mais le protocole est SSL (https). En général, le numéro de port sécurisé utilisé est 8443. L'utilisation d'un port non sécurisé pour une communication sécurisée entraîne l'échec du handshake SSL.
En règle générale, cela peut se produire si vous avez manqué des étapes ou défini des valeurs incorrectes lors de la configuration de SSL entre le routeur et le processeur de messages. Reportez-vous aux étapes décrites ici.
Par exemple, cette erreur peut se produire si
1. Le numéro de port est spécifié comme 8998 au lieu de 8443 dans /opt/apigee/customer/application/message-processor.properties as shown below
```
        conf/message-processor-communication.properties+local.http.port=8998
```
2. Les fichiers de configuration du routeur sous le répertoire /opt/nginx/conf.d/* ne sont pas supprimés et le routeur n'a pas été redémarré lors de la configuration SSL. Dans ce scénario, vous pouvez constater que le numéro de port des processeurs de messages reste 8998 dans les fichiers de configuration.

Solution

Assurez-vous que toutes les étapes décrites dans Configurer TLS entre un routeur et un processeur de messages sont correctement suivies.
Si le problème persiste, consultez la section Recueillir des informations de diagnostic.

Cause : Erreur du serveur backend

Diagnostic

Si l'erreur se produit à chaque fois, vous pouvez capturer le traçage de l'interface utilisateur pour les requêtes ayant échoué. Sélectionnez une requête ayant échoué et parcourez les différentes phases du traçage. Si vous constatez que vous obtenez l'erreur "502 Bad Gateway" du serveur backend lui-même, le problème peut être dû à une défaillance sur le serveur backend.
Traçage indiquant que l'erreur 502 Bad Gateway provient du serveur backend
Si le problème est intermittent et que vous ne parvenez pas à capturer le traçage,
1. Si vous êtes un utilisateur du cloud public, vous pouvez utiliser API Monitoring et vérifier les détails des erreurs 502.
  1. Si vous constatez que le code d'erreur est messaging.adaptors.http.flow.ErrorResponseCode et que la source de l'erreur est target, l'erreur est causée par le serveur backend.
2. Si vous êtes un utilisateur du cloud privé, vous pouvez analyser les journaux d'accès NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
  L'entrée de la requête ayant échoué s'affiche comme suit :
```
2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
```
  1. Si vous constatez que le code d'erreur est messaging.adaptors.http.flow.ErrorResponseCode et que la source de l'erreur est target, l'erreur est causée par le serveur backend.

Solution

Collaborez avec votre équipe de serveur backend pour résoudre ce problème dans le backend.

Recueillir des informations de diagnostic

Journaux d'accès NGINX
(/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
et journaux d'erreurs
(/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
Journaux du processeur de messages
(/opt/apigee/var/log/edge-message-processor/logs/system.log).