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

502 Passerelle incorrecte

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

Problème constaté

L'application cliente reçoit un code d'état HTTP 502 avec le message "Bad Gateway" comme 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 devant traiter la requête.

Messages d'erreur

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

HTTP/1.1 502 Bad Gateway

Il est également possible que les messages d'erreur suivants s'affichent:

<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, le message ci-dessous peut s'afficher. 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 qui peuvent entraîner l'erreur 502 : passerelle incorrecte pour les API passant par Apigee Edge :

Cause	Description	Instructions de dépannage applicables à
Aucun MP disponible dans la réserve	Cette erreur se produit lorsque tous les MP du pool sont indisponibles, c'est-à-dire s'ils sont en panne ou occupés et qu'ils ne répondent donc pas.	Utilisateurs du cloud privé périphérique
Configuration SSL incorrecte entre les routeurs et les MP	Cette erreur se produit si le certificat racine signé par l'autorité de certification du client est manquant dans le magasin de confiance du routeur Edge.	Utilisateurs du cloud privé périphérique
Erreur du serveur backend	Cette erreur est observée en cas de défaillance du serveur backend et d'envoyer cette réponse.	Utilisateurs Edge Public et Private Cloud

Cause: aucun MP disponible dans le pool

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

Apigee Edge est configuré de manière à ce que le trafic d'API entrant (requêtes) dans une région ou un centre de données donné soit toujours acheminé depuis les routeurs vers les processeurs de messages de la même région/centre de données. Dans certains cas, les composants Apigee Edge peuvent être configurés dans une seule région/centre de données et, dans certains cas, dans plusieurs régions/centres de données. Au moins deux routeurs et processeurs de messages sont configurés dans chaque région/centre de données.

Diagnostic

Déterminez la ou les régions/centres de données dans lesquels les requêtes API échouent avec l'erreur 502 "Passerelle incorrecte", s'il y a plusieurs régions/centres de données. Pour ce faire, vous pouvez identifier la région dans laquelle les utilisateurs observent des erreurs 502 ou consulter les journaux d'accès NGINX dans le répertoire /opt/apigee/var/log/edge-router/nginx/ de 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 arrêtés

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 en panne, redémarrez-les.

Ré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 les requêtes en cours

Cette erreur se produit si les routeurs constatent que tous les processeurs de messages d'une région ou d'un centre de données donnés sont indisponibles, 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 s'ils utilisent beaucoup le processeur, puis générez trois copies de threads toutes les 30 secondes à l'aide de la commande suivante:
```
<JAVA_HOME>/bin/jstack -l <pid> > <filename>
```
Si le ou les processeurs de messages utilisent beaucoup de mémoire, générez une empreinte de la mémoire à 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 désactiver le processeur et 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 journaux d'empreinte de thread, d'empreinte de la mémoire et de processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) pour vous aider à déterminer la cause de l'utilisation intensive du processeur/de la mémoire.

Cause: configuration SSL incorrecte entre les routeurs et les MP

Diagnostic

Vérifiez les journaux d'accès NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Une réponse 502 s'affiche, comme illustré 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). Des erreurs telles que celles-ci s'affichent:

	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 montre que le handshake SSL a échoué entre le routeur et le processeur de messages.
Si vous remarquez attentivement dans le message d'erreur aux étapes 1 et 2, le port # utilisé pour communiquer avec le processeur de messages est 8998, qui est un port non sécurisé mais avec le protocole SSL (https). Généralement, le numéro de port sécurisé utilisé est 8443. Étant donné qu'un port non sécurisé est utilisé pour la communication sécurisée, le handshake SSL échoue.
Cela peut généralement se produire si vous avez manqué des étapes ou si vous avez défini des valeurs incorrectes lors de la configuration du protocole SSL entre le routeur et le processeur de messages. Pour savoir comment procéder, consultez cette page.
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 dans 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 remarquer que le numéro de port des processeurs de messages reste 8998 dans les fichiers de configuration.

Résolution

Assurez-vous que toutes les étapes fournies dans la section Configuration du protocole TLS entre un routeur et un processeur de messages sont correctement suivies.
Si le problème persiste, consultez la section Collecter des informations de diagnostic.

Cause: erreur au niveau du serveur backend

Diagnostic

Si l'erreur se produit à chaque fois, vous pouvez capturer la trace de l'UI des requêtes ayant échoué. Sélectionnez une requête ayant échoué et parcourez les différentes phases de la trace. Si vous remarquez que le message "502 Bad Gateway" (Passerelle incorrecte) s'affiche depuis le serveur backend lui-même, le problème peut provenir du serveur backend.
Trace montrant une passerelle incorrecte 502 provenant du serveur backend
Si le problème est intermittent et que vous ne parvenez pas à capturer la trace,
1. Si vous êtes un utilisateur de 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 d'erreur est target, l'erreur est causée par le serveur backend.
2. Si vous êtes un utilisateur de cloud privé, vous pouvez analyser les journaux d'accès NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
  Vous verrez l'entrée correspondant à la requête ayant échoué 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 d'erreur est target, l'erreur est causée par le serveur backend.

Résolution

Collaborez avec l'équipe du serveur backend pour résoudre ce problème dans le backend.

Collecte d'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)