502 Nieprawidłowy limit czasu bramy

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Krótki opis problemu

Aplikacja kliencka otrzymuje błąd 502 Bad Gateway. Procesor wiadomości zwraca ten błąd aplikacji klienckiej, gdy nie otrzymuje odpowiedzi z serwera backendu.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 502 Bad Gateway

Oprócz tego może pojawić się ten komunikat o błędzie:

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

Możliwa przyczyna

Prawdopodobną przyczynę tego problemu znajdziesz w poniższej tabeli:

Przyczyna Opis Rozwiązanie problemu może wykonać
Upłynął limit czasu uzgadniania połączenia TLS/SSL Podczas uzgadniania połączenia TLS/SSL między procesorem wiadomości a serwerem backendu następuje przekroczenie limitu czasu. Użytkownicy chmury prywatnej i publicznej Cloud

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 wiadomości brzegowym a serwerem backendu.

Uzgadnianie połączenia TLS/SSL składa się z kilku etapów. Ten błąd występuje zazwyczaj w przypadku przekroczenia limitu czasu uzgadniania połączenia TLS/SSL między procesorem wiadomości a serwerem backendu.

Diagnostyka

Ta sekcja wyjaśnia, jak prawidłowo zdiagnozować limit czasu uzgadniania połączenia TLS/SSL. Wyświetlą się instrukcje dotyczące Edge Private Cloud i Public Cloud.

Zbadaj dane wyjściowe sesji śledzenia

Poniżej opisujemy, jak przeprowadzić wstępną diagnozę problemu za pomocą narzędzia Apigee Edge Trace.

  1. W interfejsie użytkownika Edge włącz sesję śledzenia dla serwera proxy interfejsu API, którego dotyczy problem.

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

    1. Sprawdź, czy błąd 502 nieprawidłowa brama występuje po 55 sekundach (jest to domyślny okres oczekiwania ustawiony przez procesor wiadomości). Jeśli błąd występuje po 55 sekundach, będzie to oznaczać, że prawdopodobną przyczyną problemu był przekroczenie limitu czasu.
    2. Sprawdź, czy błąd jest spowodowany błędem messaging.adaptors.http.BadGateway. Ten błąd zwykle oznacza przekroczenie limitu czasu.

    3. Jeśli korzystasz z Edge Private Cloud, zwróć uwagę na wartość pola X-Apigee.Message-ID w danych wyjściowych logu czasu, jak pokazano poniżej. Użytkownik Private Cloud może użyć tej wartości identyfikatora do dalszych problemów, co wyjaśnimy później.

      1. Kliknij ikonę Analytics Data Recorded (Zarejestrowane dane Analytics) na ścieżce śledzenia:

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

Aby sprawdzić, czy przyczyną błędu był czas oczekiwania na uzgadnianie połączenia TLS/SSL, wykonaj czynności opisane w poniższych sekcjach w zależności od tego, czy korzystasz z chmury publicznej czy Private Cloud.

Dodatkowe kroki diagnostyczne tylko dla użytkowników Edge Private Cloud

Jeśli korzystasz z Apigee Edge Private Cloud, możesz wykonać poniższe czynności, aby sprawdzić przyczynę błędu uzgadniania połączenia. W tym kroku sprawdzisz plik dziennika procesora wiadomości, aby znaleźć odpowiednie informacje. Jeśli korzystasz z Edge Public Cloud, możesz pominąć tę sekcję i przejść do sekcji Dalsze kroki diagnostyczne dla użytkowników chmury prywatnej i publicznej.

  1. Sprawdź, czy możesz połączyć się z określonym serwerem backendu bezpośrednio z każdego procesora wiadomości przy użyciu polecenia telnet:

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

      telnet BackendServer-IPaddress 443

    2. Jeśli serwer backendu ma wiele adresów IP, użyj nazwy hosta serwera backendu w poleceniu telnet w podany niżej sposób:

      telnet BackendServer-HostName 443

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

    Jeśli polecenie telnet nie powiedzie się, skontaktuj się ze swoim zespołem sieciowym, aby sprawdzić połączenie między procesorem wiadomości a serwerem backendu.

  2. Sprawdź w pliku dziennika procesora wiadomości, czy nie wystąpił błąd uzgadniania połączenia. Otwórz plik:

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

    i wyszukaj unikalny identyfikator wiadomości (wartość X-Apigee.Message-ID znaleziony w pliku śledzenia). Sprawdź, czy wyświetlany jest komunikat o błędzie uzgadniania połączenia 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 ten błąd pojawi się w pliku dziennika procesora wiadomości, kontynuuj analizę zagrożeń. Otwórz artykuł Dalsze kroki diagnostyczne dla użytkowników prywatnych i publicznych Cloud Edge.

Jeśli w pliku dziennika nie widzisz komunikatu uzgadniania połączenia, przejdź do Must Gather Diagnostic Information (Wymagane zbieranie informacji diagnostycznych).

Dalsze kroki diagnostyczne dla użytkowników prywatnych i publicznych chmury Edge

Aby dokładniej określić problem, możesz użyć narzędzia tcpdump do przeanalizowania pakietów TCP/IP w celu sprawdzenia, czy podczas uzgadniania połączenia TLS/SSL wystąpił limit czasu.

  1. Jeśli jesteś użytkownikiem Private Cloud, możesz przechwytywać pakiety TCP/IP na serwerze backendu lub procesorze wiadomości. Najlepiej przechwytywać je na serwerze backendu, ponieważ pakiety są odszyfrowywane na serwerze backendu.
  2. Jeśli jesteś użytkownikiem chmury publicznej, nie masz dostępu do procesora wiadomości, ale przechwytywanie pakietów TCP/IP na serwerze backendu może pomóc w określeniu problemu.

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

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

    • Jeśli odbierasz pakiety TCP/IP z serwera backendu, użyj publicznego adresu IP procesora wiadomości w poleceniu tcpdump. Informacje o korzystaniu z tego polecenia do badania ruchu na serwerze backendu znajdziesz w tcpdump.

    • Jeśli przyjmujesz pakiety TCP/IP przez procesor wiadomości, użyj publicznego adresu IP serwera backendu w poleceniu tcpdump. Jeśli potrzebujesz pomocy przy używaniu polecenia do badania ruchu procesora wiadomości, przeczytaj tcpdump.

    • Jeśli jest wiele adresów IP serwera backendu/procesora wiadomości, musisz wypróbować inne polecenie tcpdump. Więcej informacji o tym narzędziu i jego innych wariantach znajdziesz w tcpdump.

  4. Przeanalizuj pakiety TCP/IP za pomocą narzędzia Wireshark lub podobnego. Poniższy zrzut ekranu przedstawia pakiety TCP/IP w programie Wireshark.

  5. W danych wyjściowych programu Wireshark można zauważyć, że trójkierunkowe uzgadnianie połączenia TCP kończy się powodzeniem w pierwszych 3 pakietach.

  6. Procesor wiadomości wysyła następnie komunikat „Client Hello” w pakiecie nr 4.

  7. Ponieważ nie ma potwierdzenia z serwera backendu, podmiot przetwarzający wiadomości ponownie przesyła komunikat „Cześć klienta” kilka razy w pakietach 5, 6 i 7 po odczekaniu wstępnie zdefiniowanego przedziału czasu.

  8. Gdy po 3 ponownych próbach procesor wiadomości nie otrzyma żadnego potwierdzenia, wysyła komunikat FIN, ACK do serwera backendu, aby wskazać, że kończy połączenie.

  9. Jak widać w przykładowej sesji Wireshark, połączenie z backendem jest udane (krok 1), jednak uzgadnianie połączenia SSL zostało przekroczony, ponieważ serwer backendu nie odpowiedział.

Jeśli po wykonaniu czynności opisanych w tym scenariuszu okaże się, że przekroczenie limitu czasu spowodowało błąd uzgadniania połączenia TLS/SSL, przejdź do sekcji Rozwiązanie.

Korzystanie z monitorowania interfejsów API w celu identyfikacji problemu

Monitorowanie interfejsów API umożliwia szybkie wykrywanie obszarów problemów, co pozwala diagnozować problemy z błędami, wydajnością i opóźnieniami oraz ich źródła, takie jak aplikacje dla deweloperów, serwery proxy interfejsów API, cele backendu czy platforma API.

Skorzystaj z przykładowego scenariusza, który pokazuje, jak rozwiązywać problemy z kodami 5xx z interfejsami API za pomocą monitorowania interfejsów 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ść

Zazwyczaj limity czasu uzgadniania połączenia SSL wynikają z ograniczeń zapory sieciowej na serwerze backendu, które blokują ruch z Apigee Edge. Jeśli po wykonaniu czynności diagnostycznych okaże się, że przyczyną błędu uzgadniania połączenia jest przekroczenie czasu oczekiwania, musisz skontaktować się z zespołem ds. sieci, aby zidentyfikować przyczynę i naprawić ograniczenia zapory sieciowej.

Pamiętaj, że ograniczenia zapory sieciowej mogą być nakładane na różne warstwy sieci. Aby zapewnić płynny przepływ ruchu między Apigee Edge a serwerem backendu, należy usunąć ograniczenia dotyczące wszystkich warstw sieci związanych z adresami IP procesora wiadomości.

Jeśli nie ma ograniczeń zapory sieciowej lub problem nadal występuje, przejdź do artykułu Must Gather diagnostic Information (Wymagane jest zbieranie informacji diagnostycznych).

Musi gromadzić informacje diagnostyczne

Jeśli problem nie ustąpi mimo wykonania powyższych instrukcji, zbierz poniższe informacje diagnostyczne. Skontaktuj się z zespołem pomocy Apigee Edge i udostępnij je:

  1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
    1. Nazwa organizacji
    2. Nazwa środowiska
    3. Nazwa serwera proxy interfejsu API
    4. Wykonaj polecenie curl, aby odtworzyć błąd
    5. Plik śledzenia pokazujący błąd
    6. Pakiety TCP/IP przechwycone na serwerze backendu
  2. Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:
    1. Zarejestrowano pełny komunikat o błędzie
    2. Pakiet proxy API
    3. Plik śledzenia pokazujący błąd
    4. Logi procesora wiadomości /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Pakiety TCP/IP przechwycone na serwerze backendu lub procesorze wiadomości.
  3. Szczegóły wypróbowanych przez Ciebie sekcji tego Poradnika oraz inne informacje, które pomogą nam przyspieszyć rozwiązanie tego problemu.