502 Nieprawidłowa brama

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 502 z komunikatem „Bad Gateway” w odpowiedzi na wywołania interfejsu API.

Kod stanu HTTP 502 oznacza, że klient nie otrzymuje prawidłowej odpowiedzi z serwerów backendu, które powinny zrealizować żądanie.

Komunikaty o błędach

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 502 Bad Gateway

Dodatkowo możesz zobaczyć te komunikaty o błędach:

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

Jeśli błąd pochodzi z serwera backendu, możesz zobaczyć coś takiego. Komunikat o błędzie z backendu zależy całkowicie od jego implementacji.

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

Możliwe przyczyny

Oto kilka możliwych przyczyn, które mogą prowadzić do błędu 502 Bad Gateway w przypadku interfejsów API przechodzących przez Apigee Edge:

Przyczyna: brak procesorów wiadomości w puli

Ten błąd występuje, jeśli router stwierdzi, że wszystkie procesory wiadomości w danym regionie lub centrum danych są niedostępne (np. jeśli wszystkie są wyłączone).

Apigee Edge jest skonfigurowana w taki sposób, że przychodzący ruch API (żądania) w danym regionie lub centrum danych jest zawsze kierowany z routerów do procesorów wiadomości w tym samym regionie lub centrum danych. W niektórych przypadkach komponenty Apigee Edge mogą być skonfigurowane tylko w 1 regionie lub centrum danych, a w innych – w więcej niż 1 regionie lub centrum danych. W każdym regionie lub centrum danych skonfigurowane są co najmniej 2 routery i procesory wiadomości.

Diagnostyka

1. Określ region lub centrum danych, w którym żądania API kończą się niepowodzeniem z powodu błędu 502 Bad Gateway, jeśli jest więcej niż 1 region lub centrum danych. Możesz to sprawdzić, identyfikując region, w którym użytkownicy obserwują błędy 502, lub sprawdzając dzienniki dostępu NGINX w katalogu /opt/apigee/var/log/edge-router/nginx/ na każdym z routerów należących do różnych regionów.
2. W dziennikach błędów NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log)
   zobaczysz ten błąd:

   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>"

Scenariusz 1. Wszystkie procesory wiadomości są wyłączone

1. Sprawdź, czy procesory wiadomości w danym regionie lub centrum danych są włączone i działają.
2. Jeśli wszystkie procesory wiadomości są wyłączone, uruchom je ponownie.

Rozwiązanie

Uruchom ponownie wszystkie procesory wiadomości za pomocą tego polecenia:

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

Scenariusz 2. Wszystkie procesory wiadomości są zajęte przetwarzaniem bieżących żądań

Ten błąd występuje, jeśli routery stwierdzą, że wszystkie procesory wiadomości w danym regionie lub centrum danych są niedostępne, ponieważ są zajęte przetwarzaniem bieżących żądań.

1. Sprawdź, czy procesory wiadomości w danym regionie lub centrum danych są włączone i działają.
2. Jeśli wszystkie procesory komunikatów są włączone i aktywne, sprawdź, czy procesor lub procesory komunikatów mają wysokie wykorzystanie procesora. Następnie wygeneruj 3 zrzuty wątków co 30 sekund za pomocą tego polecenia:
   

   <JAVA_HOME>/bin/jstack -l <pid> > <filename>

3. Jeśli procesor lub procesory wiadomości mają wysokie wykorzystanie pamięci, wygeneruj zrzut sterty za pomocą tego polecenia:
   

   sudo -u apigee /bin/jmap -dump:live,format=b,file= 

4. Uruchom ponownie procesor komunikatów za pomocą tego polecenia. Powinno to zmniejszyć wykorzystanie procesora i pamięci:
   

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

5. Monitoruj wywołania interfejsu API, aby sprawdzić, czy problem nadal występuje.
6. Skontaktuj się z zespołem pomocy Apigee i prześlij zrzuty wątków, zrzut stosu oraz dzienniki procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log), aby pomóc w zbadaniu przyczyny wysokiego wykorzystania procesora lub wykorzystania pamięci.

Przyczyna: nieprawidłowa konfiguracja SSL między routerami a procesorami wiadomości

Diagnostyka

1. Sprawdź dzienniki dostępu NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Zobaczysz odpowiedź 502, jak pokazano poniżej:
   

       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	-

2. Sprawdź dzienniki błędów NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Zobaczysz błędy takie jak ten:
   

   	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>"

3. Wskazuje to, że nie udało się uzgodnić połączenia za pomocą protokołu SSL między routerem a procesorem komunikatów.
4. Jeśli dokładnie przyjrzysz się komunikatowi o błędzie w kroku 1 i 2, zobaczysz, że port używany do komunikacji z procesorem komunikatów to 8998, który jest portem niezabezpieczonym, ale protokół to SSL (https). Zwykle używany jest port bezpieczny 8443. Ponieważ do bezpiecznej komunikacji używany jest port niezabezpieczony, powoduje to niepowodzenie uzgodnienia połączenia za pomocą protokołu SSL.
5. Zazwyczaj może się to zdarzyć, jeśli podczas konfigurowania protokołu SSL między routerem a procesorem komunikatów pominiesz jakieś kroki lub ustawisz nieprawidłowe wartości. Wykonaj czynności opisane tutaj.
   Ten błąd może na przykład wystąpić, jeśli:
   
   1. W pliku /opt/apigee/customer/application/message-processor.properties as shown below
      port został określony jako 8998 zamiast 8443

              conf/message-processor-communication.properties+local.http.port=8998

   2. Pliki konfiguracyjne routera w katalogu /opt/nginx/conf.d/* nie zostały usunięte, a router nie został ponownie uruchomiony podczas konfigurowania protokołu SSL. W tym scenariuszu możesz zauważyć, że w plikach konfiguracyjnych port procesorów wiadomości pozostanie 8998.

Rozwiązanie

1. Upewnij się, że wszystkie kroki opisane w artykule Konfigurowanie protokołu TLS między routerem a procesorem komunikatów zostały wykonane prawidłowo.
2. Jeśli problem nadal występuje, przejdź do sekcji Zbieranie informacji diagnostycznych.

Przyczyna: błąd z serwera backendu

Diagnostyka

1. Jeśli błąd występuje za każdym razem, możesz przechwycić ślad interfejsu nieudanych żądań. Wybierz nieudane żądanie i przejdź przez różne fazy śledzenia. Jeśli zauważysz, że otrzymujesz komunikat „502 Bad Gateway” z serwera backendu, problem może być spowodowany awarią serwera backendu.
   Ślad pokazujący błąd 502 Bad Gateway pochodzący z serwera backendu
   
2. Jeśli problem występuje sporadycznie i nie możesz przechwycić śladu:
   
   1. Jeśli jesteś użytkownikiem chmury publicznej, możesz użyć monitorowania interfejsu API i sprawdzić szczegóły błędów 502.
      
      1. Jeśli zauważysz, że kod błędu to messaging.adaptors.http.flow.ErrorResponseCode, a źródło błędu to target, oznacza to, że błąd jest spowodowany przez serwer backendu.
   2. Jeśli jesteś użytkownikiem chmury prywatnej, możesz przeanalizować dzienniki dostępu NGINX
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      Wpis dotyczący nieudanego żądania będzie wyglądać tak:
      

      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. Jeśli zauważysz, że kod błędu to messaging.adaptors.http.flow.ErrorResponseCode, a źródło błędu to target, oznacza to, że błąd jest spowodowany przez serwer backendu.

Rozwiązanie

1. Współpracuj z zespołem serwera backendu, aby rozwiązać ten problem w backendzie.

Zbieranie informacji diagnostycznych

1. Dzienniki dostępu NGINX
   (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
   i dzienniki błędów
   (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
2. Dzienniki procesora komunikatów
   (/opt/apigee/var/log/edge-message-processor/logs/system.log).