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

502 Passerelle incorrecte

<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 un code d'état HTTP 502 avec le message Bad Gateway (Passerelle incorrecte) 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 du des serveurs backend qui doivent réellement répondre à la requête.

Messages d'erreur

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

HTTP/1.1 502 Bad Gateway

Les messages d'erreur suivants peuvent également s'afficher:

<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, un message de ce type 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 pouvant entraîner l'erreur 502 Bad Gateway pour les API passant par Apigee Edge:

Cause	Description	Instructions de dépannage applicables à
Aucun MP disponible dans le pool	Cette erreur se produit si tous les MP du pool sont indisponibles, c'est-à-dire lorsqu'ils sont arrêtés ou occupés, et qu'ils ne répondent donc pas.	Utilisateurs du cloud privé Edge
Configuration SSL incorrecte entre les routeurs et les MP	Cette erreur se produit si le certificat racine signé par une autorité de certification du client est manquant dans le Truststore du routeur Edge.	Utilisateurs du cloud privé Edge
Erreur du serveur backend	Cette erreur sera observée si le serveur backend tombe en panne et envoie cette réponse.	Utilisateurs Edge de cloud public et privé

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 en panne).

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

Diagnostic

Déterminez 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/ sur chacun des routeurs appartenant à différentes régions.

L'erreur suivante s'affichera 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 en panne

Vérifiez si les processeurs de messages de la région ou du centre de données concernés sont opérationnels.
Si tous les processeurs de messages sont en panne, 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 détectent 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 sollicitent 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 consomment 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 réduire 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-lui les empreintes 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 à rechercher la cause de cette utilisation élevée du processeur ou 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). Vous verrez une réponse 502 comme 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	-

Vérifiez les journaux d'erreurs NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Des erreurs de ce type s'afficheront:

	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 la négociation SSL échoue entre le routeur et le processeur de messages.
Si vous remarquez attentivement dans le message d'erreur des étapes 1 et 2, le port # utilisé pour communiquer avec le processeur de messages est 8998 qui est un port non sécurisé mais le protocole est SSL (https). Généralement, le numéro de port sécurisé utilisé est 8443. Puisqu'un port non sécurisé est utilisé pour une communication sécurisée, il entraîne l'échec de la négociation SSL.
En général, cela peut se produire si vous avez manqué des étapes ou défini des valeurs incorrectes lors de la configuration du protocole SSL entre le routeur et le processeur de messages. Reportez-vous aux étapes décrites sur cette page.
Par exemple, cette erreur peut se produire si
<ph type="x-smartling-placeholder">
1. Le numéro de port spécifié est 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 figurant dans le répertoire /opt/nginx/conf.d/* ne sont pas supprimés et le routeur n'a pas été redémarré pendant la configuration SSL. Dans ce scénario, vous pouvez remarquer que le numéro de port des processeurs de messages restera 8998 dans les fichiers de configuration.

Solution

Assurez-vous que toutes les étapes fournies dans Configuration du protocole TLS entre un routeur et un processeur de messages sont correctement suivies.
Si le problème persiste, consultez Recueillir 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'interface utilisateur pour les requêtes en échec. Sélectionnez une requête en échec et parcourez les différentes phases de la trace. Si vous constatez que le message "502 Bad Gateway" s'affiche sur le serveur backend lui-même, le problème peut provenir du serveur backend.
Trace affichant une erreur 502 (passerelle incorrecte) en provenance du serveur backend
Si le problème se produit par intermittence et que vous ne parvenez pas à capturer la trace,
<ph type="x-smartling-placeholder">
1. Si vous êtes un utilisateur de cloud public, vous pouvez utiliser API Monitoring et vérifier les détails sur les erreurs 502.
  1. Si vous observez 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 utilisez le 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 correspondant à 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
```
  <ph type="x-smartling-placeholder">
  1. Si vous observez 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

Contactez l'équipe chargée de votre 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).