502 Nieprawidłowy limit czasu bramy

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Krótki opis problemu

Aplikacja kliencka otrzymuje błąd 502: Nieprawidłowa brama. Procesor komunikatów zwraca ten błąd do aplikacji klienckiej, gdy nie otrzyma odpowiedzi z serwera backendu.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 502 Bad Gateway

Może też pojawić się ten komunikat o błędzie:

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Możliwa przyczyna

Możliwe przyczyny tego problemu znajdziesz w tej tabeli:

Przyczyna: przekroczenie limitu czasu uzgadniania połączenia TLS/SSL

W Apigee Edge możesz skonfigurować połączenie TLS/SSL z serwerem backendu, aby włączyć komunikację TLS między procesorem komunikatów Edge a serwerem backendu.

Uzgadnianie połączenia TLS/SSL obejmuje kilka etapów. Ten błąd występuje zwykle, gdy podczas uzgadniania połączenia TLS/SSL między procesorem komunikatów a serwerem backendu nastąpi przekroczenie limitu czasu.

Diagnostyka

Z tej sekcji dowiesz się, jak prawidłowo zdiagnozować przekroczenie limitu czasu uzgadniania połączenia TLS/SSL. Znajdziesz tu instrukcje dotyczące chmury prywatnej i publicznej Edge.

Sprawdzanie danych wyjściowych sesji śledzenia

Z tych instrukcji dowiesz się, jak przeprowadzić wstępną diagnostykę problemu za pomocą narzędzia śledzenia Apigee Edge.

1. W interfejsie Edge włącz sesję śledzenia dla danego proxy interfejsu API.

2. Jeśli ślad nieudanego żądania do interfejsu API pokazuje te informacje, prawdopodobnie wystąpił błąd przekroczenia limitu czasu uzgadniania połączenia TLS/SSL. Prawdopodobną przyczyną błędu jest to, że zapora serwera backendu blokuje ruch z Apigee.

   1. Sprawdź, czy błąd 502: Nieprawidłowa brama występuje po 55 sekundach, co jest domyślnym czasem oczekiwania ustawionym w procesorze komunikatów. Jeśli widzisz, że błąd wystąpił po 55 sekundach, oznacza to, że prawdopodobną przyczyną problemu było przekroczenie limitu czasu.
   2. Sprawdź, czy błąd pokazuje przyczynę: messaging.adaptors.http.BadGateway. Ten błąd zwykle wskazuje na przekroczenie limitu czasu.

   3. Jeśli korzystasz z chmury prywatnej Edge, zanotuj wartość pola X-Apigee.Message-ID w danych wyjściowych śledzenia, jak pokazano poniżej. Użytkownik chmury prywatnej może użyć tej wartości identyfikatora do dalszego rozwiązywania problemów, jak opisano poniżej.

      1. W ścieżce śledzenia kliknij ikonę Zapisane dane analityczne:

         

      2. Przewiń w dół i zanotuj wartość pola X-Apigee.Message-ID.

Aby potwierdzić, że przyczyną błędu było przekroczenie limitu czasu uzgadniania połączenia TLS/SSL, wykonaj czynności opisane w kolejnych sekcjach, w zależności od tego, czy korzystasz z chmury publicznej czy prywatnej.

Dodatkowe instrukcje diagnostyczne tylko dla użytkowników chmury prywatnej Edge

Jeśli korzystasz z chmury prywatnej Apigee Edge, możesz wykonać te czynności, aby sprawdzić przyczynę błędu uzgadniania. W tym kroku sprawdzisz plik dziennika procesora komunikatów pod kątem odpowiednich informacji. Jeśli korzystasz z chmury publicznej Edge, możesz pominąć tę sekcję i przejść do dalszych instrukcji diagnostycznych dla użytkowników chmury prywatnej i publicznej.

1. Sprawdź, czy możesz połączyć się z konkretnym serwerem backendu bezpośrednio z każdego procesora komunikatów za pomocą polecenia telnet:

   1. Jeśli serwer backendu jest rozpoznawany jako pojedynczy adres IP, użyj tego polecenia:

      telnet BackendServer-IPaddress 443

   2. Jeśli serwer backendu jest rozpoznawany jako wiele adresów IP, użyj nazwy hosta serwera backendu w poleceniu telnet, jak pokazano poniżej:

      telnet BackendServer-HostName 443

   Jeśli możesz połączyć się z serwerem backendu bez żadnych błędów, przejdź do następnego kroku.

   Jeśli polecenie telnet się nie powiedzie, musisz skontaktować się z zespołem ds. sieci, aby sprawdzić połączenie między procesorem komunikatów a serwerem backendu.

2. Sprawdź plik dziennika procesora komunikatów pod kątem dowodów na nieudane uzgadnianie. Otwórz plik:

   /opt/apigee/var/log/edge-message-processor/system.log

   i wyszukaj unikalny identyfikator wiadomości (wartość X-Apigee.Message-ID , którą znajdziesz w pliku śledzenia). Sprawdź, czy widzisz komunikat o błędzie uzgadniania powiązany z identyfikatorem wiadomości, jak pokazano poniżej:

   org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
   HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
   isOpen=true handshake timeout
   

Jeśli widzisz ten błąd w pliku dziennika procesora komunikatów, kontynuuj dalsze badanie. Przejdź do dalszych instrukcji diagnostycznych dla użytkowników chmury prywatnej i publicznej Edge.

Jeśli nie widzisz komunikatu o uzgadnianiu w pliku dziennika, przejdź do sekcji Informacje diagnostyczne, które należy zebrać.

Dalsze instrukcje diagnostyczne dla użytkowników chmury prywatnej i publicznej Edge

Aby dokładniej określić przyczynę problemu, możesz użyć narzędzia tcpdump do analizowania pakietów TCP/IP i sprawdzenia, czy podczas uzgadniania połączenia TLS/SSL nastąpiło przekroczenie limitu czasu.

1. Jeśli jesteś użytkownikiem chmury prywatnej, możesz przechwycić pakiety TCP/IP na serwerze backendu lub procesorze komunikatów. Najlepiej przechwytywać je na serwerze backendu, ponieważ pakiety są na nim odszyfrowywane.
2. Jeśli jesteś użytkownikiem chmury publicznej, nie masz dostępu do procesora komunikatów . Przechwytywanie pakietów TCP/IP na serwerze backendu może jednak pomóc w ustaleniu przyczyny problemu .

3. Po wybraniu miejsca, w którym chcesz przechwytywać pakiety TCP/IP, użyj tego polecenia tcpdump , aby je przechwycić.

   tcpdump -i any -s 0 host <IP address> -w <File name>
   

   • Jeśli przechwytujesz pakiety TCP/IP na serwerze backendu, użyj publicznego adresu IP procesora komunikatów w poleceniu tcpdump. Aby uzyskać pomoc dotyczącą używania polecenia do sprawdzania ruchu na serwerze backendu, przeczytaj artykuł tcpdump.

   • Jeśli przechwytujesz pakiety TCP/IP na procesorze komunikatów, użyj publicznego adresu IP serwera backendu w poleceniu tcpdump. Aby uzyskać pomoc dotyczącą używania polecenia do sprawdzania ruchu procesora komunikatów, przeczytaj artykuł tcpdump.

   • Jeśli serwer backendu lub procesor komunikatów ma wiele adresów IP, musisz użyć innego polecenia tcpdump. Więcej informacji o tym narzędziu i innych wariantach tego polecenia znajdziesz w artykule tcpdump.

4. Przeanalizuj pakiety TCP/IP za pomocą narzędzia Wireshark lub podobnego. Zrzut ekranu poniżej przedstawia pakiety TCP/IP w Wiresharku.

   

5. Z danych wyjściowych Wiresharka wynika, że trójstronne uzgadnianie połączenia TCP zostało pomyślnie zakończone w pierwszych 3 pakietach.

6. Następnie procesor komunikatów wysyła komunikat „Client Hello” w pakiecie nr 4.

7. Ponieważ serwer backendu nie wysyła potwierdzenia, procesor komunikatów po upływie określonego czasu ponownie przesyła komunikat „Client Hello” w pakietach 5, 6 i 7.

8. Gdy procesor komunikatów nie otrzyma potwierdzenia po 3 próbach, wysyła do serwera backendu komunikat FIN, ACK , aby wskazać, że zamyka połączenie.

9. Jak pokazano w przykładowej sesji Wiresharka, połączenie z backendem zostało nawiązane (krok 1), ale przekroczono limit czasu uzgadniania połączenia SSL, ponieważ serwer backendu nie odpowiedział.

Jeśli po wykonaniu instrukcji rozwiązywania problemów opisanych w tym przewodniku stwierdzisz, że przyczyną błędu uzgadniania połączenia TLS/SSL było przekroczenie limitu czasu, przejdź do sekcji Rozwiązanie.

Identyfikowanie problemu za pomocą monitorowania interfejsu API

Monitorowanie interfejsu API umożliwia szybkie wyodrębnianie obszarów problemowych w celu diagnozowania błędów, problemów z wydajnością i opóźnieniami oraz ich źródła, np. aplikacji deweloperów, proxy interfejsu API, celów backendu lub platformy interfejsu API.

Zapoznaj się z przykładowym scenariuszem który pokazuje, jak rozwiązywać problemy z kodami 5xx w interfejsach API za pomocą monitorowania interfejsu API. Możesz na przykład skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba błędów messaging.adaptors.http.BadGateway przekroczy określony próg.

Rozdzielczość

Zwykle przekroczenie limitu czasu uzgadniania połączenia SSL występuje z powodu ograniczeń zapory na serwerze backendu, które blokują ruch z Apigee Edge. Jeśli po wykonaniu instrukcji diagnostycznych stwierdzisz, że przyczyną błędu uzgadniania jest przekroczenie limitu czasu, musisz skontaktować się z zespołem ds. sieci, aby ustalić przyczynę i usunąć ograniczenia zapory.

Pamiętaj, że ograniczenia zapory mogą być nałożone na różnych warstwach sieci. Aby zapewnić płynny przepływ ruchu między Apigee Edge a serwerem backendu, musisz usunąć ograniczenia na wszystkich warstwach sieci dotyczące adresów IP procesora komunikatów.

Jeśli nie ma ograniczeń zapory lub problem nadal występuje, przejdź do sekcji Informacje diagnostyczne, które należy zebrać.

Informacje diagnostyczne, które należy zebrać

Jeśli problem nadal występuje po wykonaniu powyższych instrukcji, zbierz te informacje diagnostyczne. Skontaktuj się z zespołem pomocy Apigee Edge i udostępnij mu te informacje:

1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
   1. Nazwa organizacji
   2. Nazwa środowiska
   3. Nazwa proxy interfejsu API
   4. Pełne polecenie curl do odtworzenia błędu
   5. Plik śledzenia pokazujący błąd
   6. Pakiety TCP/IP przechwycone na serwerze backendu
2. Jeśli jesteś użytkownikiem chmury prywatnej, podaj te informacje:
   1. Pełny komunikat o błędzie
   2. Pakiet proxy interfejsu API
   3. Plik śledzenia pokazujący błąd
   4. Dzienniki procesora komunikatów /opt/apigee/var/log/edge-message-processor/logs/system.log
   5. Pakiety TCP/IP przechwycone na serwerze backendu lub procesorze komunikatów.
3. Szczegółowe informacje o tym, które sekcje tego przewodnika zostały przez Ciebie sprawdzone, oraz wszelkie inne informacje, które pomogą nam szybciej rozwiązać ten problem.