502 Nieprawidłowa brama

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 502 z komunikatem „Nieprawidłowa brama” jako odpowiedź na wywołania interfejsu API.

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

Komunikaty o błędach

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 502 Bad Gateway

Możesz też 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 w pełni zależy 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 błędu 502 Nieprawidłowa brama w przypadku interfejsów API przechodzących przez Apigee Edge:

Przyczyna Opis Instrukcje dotyczące rozwiązywania problemów dotyczące
Brak miejsc MP na puli Ten błąd jest zaobserwowany, gdy wszystkie MP w puli są niedostępne, tzn. nie odpowiadają lub są zajęte. Użytkownicy Edge Private Cloud
Nieprawidłowa konfiguracja SSL między routerami i MP Ten błąd jest obserwowany, jeśli w magazynie zaufania routera Edge brakuje certyfikatu głównego podpisanego przez klienta (CA). Użytkownicy Edge Private Cloud
Błąd serwera backendu Ten błąd zostanie zaobserwowany, gdy serwer backendu wyśle tę odpowiedź. Użytkownicy chmury publicznej i prywatnej chmury

Przyczyna: brak dostępnych parlamentarzystów

Ten błąd występuje, gdy router wykryje, że wszystkie procesory wiadomości w danym regionie/centrum danych są niedostępne (na przykład gdy wszystkie nie działają).

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

Diagnostyka

  1. Określ region/centrum danych, w którym żądania do interfejsu API kończą się niepowodzeniem (błąd 502 – nieprawidłowa brama), jeśli istnieje więcej niż 1 region/centrum danych. Aby dowiedzieć się więcej, określ region, w którym użytkownicy zgłaszają błędy 502, lub sprawdź logi dostępu NGINX w katalogu /opt/apigee/var/log/edge-router/nginx/ w każdym z routerów należących do różnych regionów.
  2. W logach błędów NGINX pojawi się ten błąd (/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>"

Scenariusz 1. Wszystkie procesory wiadomości nie działają

  1. Sprawdź, czy procesory wiadomości w określonym regionie/określonym centrum danych są uruchomione.
  2. Jeśli wszystkie procesory wiadomości są wyłączone, uruchom je ponownie.

Rozdzielczość

Uruchom ponownie wszystkie procesory wiadomości za pomocą następującego polecenia:

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

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

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

  1. Sprawdź, czy procesory wiadomości w określonym regionie/określonym centrum danych są uruchomione.
  2. Jeśli wszystkie procesory wiadomości są włączone i aktywne, sprawdź, czy te procesory nie obciążają procesora nadmiernie, a następnie generuj 3 zrzuty wątków co 30 sekund przy użyciu następującego polecenia:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Jeśli procesory wiadomości używają dużo pamięci, wygeneruj zrzut stosu za pomocą tego polecenia:
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. Ponownie uruchom procesor wiadomości, korzystając z poniższego polecenia. Procesor i pamięć powinny zmniejszać się:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Monitoruj wywołania interfejsu API, aby potwierdzić, czy problem nadal występuje.
  6. Skontaktuj się z zespołem pomocy Apigee i udostępnij zrzuty wątków, zrzut stosu oraz logi procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log), które pomogą w zbadaniu przyczyny wysokiego wykorzystania procesora i pamięci.

Przyczyna: nieprawidłowa konfiguracja SSL między routerami i MP

Diagnostyka

  1. Sprawdź logi dostępu NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Wyświetli się 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ź logi błędów NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Zobaczysz błędy podobne do tych:
    	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. Pokazuje niepowodzenie uzgadniania połączenia SSL między routerem a procesorem wiadomości.
  4. Jeśli zauważysz komunikat o błędzie w krokach 1 i 2, możesz zauważyć, że port używany do komunikacji z procesorem wiadomości to port 8998, który nie jest bezpieczny, ale korzysta z protokołu SSL (https). Zazwyczaj używany jest bezpieczny port 8443. Ponieważ do bezpiecznej komunikacji używany jest niezabezpieczony port, powoduje to niepowodzenie uzgadniania połączenia SSL.
  5. Zwykle może się tak zdarzyć, jeśli podczas konfigurowania protokołu SSL między routerem a procesorem wiadomości pominięto jakieś kroki lub ustawiono nieprawidłowe wartości. Instrukcje znajdziesz tutaj.
    Ten błąd może wystąpić, jeśli na przykład
    1. Numer portu jest określony jako 8998 zamiast 8443 w: /opt/apigee/customer/application/message-processor.properties as shown below
              conf/message-processor-communication.properties+local.http.port=8998
    2. Pliki konfiguracji routera znajdujące się w katalogu /opt/nginx/conf.d/* nie zostaną usunięte, a router nie został ponownie uruchomiony podczas wykonywania konfiguracji SSL. W tym scenariuszu możesz zauważyć, że w plikach konfiguracyjnych numer portu# procesorów wiadomości pozostanie 8998.

Rozdzielczość

  1. Upewnij się, że wszystkie kroki opisane w artykule Konfigurowanie protokołu TLS między routerem i procesorem wiadomości zostały wykonane prawidłowo.
  2. Jeśli problem nie ustąpi, przejdź do artykułu Zbieranie informacji diagnostycznych.

Przyczyna: błąd z serwera backendu

Diagnostyka

  1. Jeśli błąd występuje za każdym razem, możesz przechwycić log czasu interfejsu dla nieudanych żądań. Wybierz nieudane żądanie i przejdź przez różne etapy logu czasu. Jeśli zauważysz, że z serwera backendu pojawia się błąd „502 (Nieprawidłowa brama”), przyczyną problemu może być błąd serwera backendu.
    Ślad pokazujący błąd 502 (Nieprawidłowa brama pochodząca z serwera backendu)
  2. Jeśli problem występuje przejściowo i nie możesz zarejestrować logu czasu,
    1. Jeśli jesteś użytkownikiem chmury publicznej, możesz użyć narzędzia Monitorowanie interfejsów API i sprawdzić szczegóły błędów 502.
      1. Jeśli widzisz, że kod błędu to messaging.adaptors.http.flow.ErrorResponseCode, a źródło błędu to target, błąd jest spowodowany przez serwer backendu.
    2. Jeśli jesteś użytkownikiem chmury prywatnej, możesz przeanalizować logi dostępu do NGINX
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      Zobaczysz taki wpis o błędnym żądaniu:
      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 widzisz, że kod błędu to messaging.adaptors.http.flow.ErrorResponseCode, a źródło błędu to target, błąd jest spowodowany przez serwer backendu.

Rozdzielczość

  1. Aby rozwiązać ten problem w backendzie, skontaktuj się z zespołem ds. serwera backendu.

Zbieranie informacji diagnostycznych

  1. Logi 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. Logi procesora wiadomości
    (/opt/apigee/var/log/edge-message-processor/logs/system.log).