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). Przetwarzacz wiadomości zwraca ten błąd do aplikacji klienta, gdy nie otrzyma odpowiedzi od serwera zaplecza.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 502 Bad Gateway

Możesz też zobaczyć ten komunikat o błędzie:

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

Możliwa przyczyna

Możliwe przyczyny tego problemu:

Przyczyna Opis Aby rozwiązać problem:
Czas oczekiwania na uzgodnienie TLS/SSL Przekroczenie limitu czasu występuje podczas uzgadniania połączenia TLS/SSL między procesorem wiadomości a serwerem zaplecza. Użytkownicy chmury prywatnej i publicznej Edge

Przyczyna: limit czasu uzgadniania połączenia TLS/SSL

W Apigee Edge możesz skonfigurować połączenie TLS/SSL z serwerem zaplecza, aby umożliwić komunikację TLS między procesorem wiadomości brzegowej a serwerem zaplecza.

Uzgadnianie połączenia TLS/SSL obejmuje kilka etapów. Ten błąd występuje zwykle, gdy czas oczekiwania na nawiązanie połączenia TLS/SSL między procesorem wiadomości a serwerem zaplecza upłynął.

Diagnostyka

W tej sekcji wyjaśniono, jak poprawnie diagnozować czas oczekiwania na uzgadnianie połączenia TLS/SSL. Zobaczysz instrukcje dotyczące Edge Private Cloud i Public Cloud.

Badanie danych wyjściowych sesji śledzenia

Podane niżej kroki pokazują, jak przeprowadzić wstępną diagnostykę problemu za pomocą narzędzia Apigee Edge Trace.

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

  2. Jeśli ślad żądania interfejsu API, które nie powiodło się, zawiera te informacje, prawdopodobnie wystąpił błąd przekroczenia limitu czasu protokołu TLS/SSL. Prawdopodobną przyczyną błędu jest to, że zapora sieciowa serwera zaplecza blokuje ruch z Apigee.

    1. Sprawdź, czy błąd 502 Nieprawidłowa brama pojawia się po 55 sekundach (jest to domyślny czas oczekiwania ustawiony w procesorze wiadomości). Jeśli widzisz, że błąd wystąpił po 55 sekundach, oznacza to, że prawdopodobnie przyczyną problemu było przekroczenie limitu czasu.
    2. Sprawdź, czy błąd wskazuje na błąd: messaging.adaptors.http.BadGateway. Ten błąd zwykle wskazuje na przekroczenie limitu czasu.

    3. Jeśli korzystasz z Edge Private Cloud, zanotuj wartość pola X-Apigee.Message-ID w danych wyjściowych z śledzenia, jak pokazano poniżej. Użytkownik prywatnego konta iCloud może użyć tej wartości identyfikatora, aby przeprowadzić dalsze czynności związane z rozwiązywaniem problemów, o których mowa poniżej.

      1. Na ścieżce śledzenia kliknij ikonę Analytics Data Recorded (Zarejestrowano dane Analytics):

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

Aby sprawdzić, czy błąd był spowodowany przez limit czasu procedury TLS/SSL Handshake, wykonaj czynności opisane w następnych sekcjach w zależności od tego, czy korzystasz z chmury publicznej czy prywatnej.

Dodatkowe czynności 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 sprawdź, czy w pliku dziennika usługi Message Processor znajdują się odpowiednie informacje. Jeśli korzystasz z Edge Public Cloud, możesz pominąć tę sekcję i przejść do sekcji Dodatkowe kroki diagnostyczne dla użytkowników chmur prywatnych i publicznych.

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

    1. Jeśli serwer zaplecza rozpoznaje tylko jeden adres IP, użyj tego polecenia:

      telnet BackendServer-IPaddress 443

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

      telnet BackendServer-HostName 443

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

    Jeśli polecenie telnet zakończy się niepowodzeniem, musisz skontaktować się z zespołem ds. sieci, aby sprawdzić łączność między procesorem wiadomości a serwerem zaplecza.

  2. Sprawdź plik dziennika usługi Message Processor, aby znaleźć dowody na błąd procesu nawiązywania połączenia. Otwórz plik:

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

    i szukaj unikalnego identyfikatora wiadomości (wartości nagłówka X-Apigee.Message-ID znalezionej w pliku z wykresami). Sprawdź, czy widzisz komunikat o błędzie 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 jest widoczny w pliku dziennika procesora wiadomości, kontynuuj badanie sprawy. Przejdź do artykułu Dodatkowe czynności diagnostyczne dla użytkowników Edge Private i Public Cloud.

Jeśli nie widzisz komunikatu dotyczącego uścisku dłoni w pliku dziennika, przejdź do sekcji Musisz zebrać informacje diagnostyczne.

Dalsze czynności diagnostyczne dla użytkowników Edge Private i Public Cloud

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

  1. Jeśli jesteś użytkownikiem Private Cloud, możesz przechwytywać pakiety TCP/IP na serwerze zaplecza lub w procesorze wiadomości. Najlepiej przechwytywać je na serwerze backendu, ponieważ pakiety są odszyfrowywane na serwerze backendu.
  2. Jeśli jesteś użytkownikiem Google Cloud, nie masz dostępu do usługi Message Processor. Przechwytywanie pakietów TCP/IP na serwerze zaplecza może jednak pomóc w zlokalizowaniu problemu.

  3. Po podjęciu decyzji, gdzie przechwycić pakiety TCP/IP, użyj polecenia tcpdump, aby przechwycić pakiety TCP/IP.

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

    • Jeśli pobierasz pakiety TCP/IP na serwerze backendu, w poleceniu tcpdump użyj publicznego adresu IP procesora wiadomości. Aby dowiedzieć się, jak za pomocą tego polecenia sprawdzać ruch na serwerze backendu, zapoznaj się z artykułem tcpdump.

    • Jeśli pobierasz pakiety TCP/IP na procesorze wiadomości, użyj w komendzie tcpdump publicznego adresu IP serwera zaplecza. Aby dowiedzieć się, jak użyć tego polecenia do sprawdzania ruchu w procesorze wiadomości, zapoznaj się z artykułem tcpdump.

    • Jeśli serwer backendu lub usługa Message Processor mają kilka adresów IP, spróbuj użyć innego polecenia tcpdump. Więcej informacji o tym narzędziu oraz o innych wariantach tego polecenia znajdziesz w artykule 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 trójkierunkowe uzgadnianie połączenia TCP zostało zakończone w ciągu pierwszych 3 pakietów.

  6. Następnie procesor wiadomości wysyła wiadomość „Client Hello” w pakiecie 4.

  7. Ponieważ nie ma potwierdzenia z serwera backendu, procesor wiadomości wielokrotnie przesyła komunikat „Client Hello” w pakietach 5, 6 i 7 po upływie określonego czasu.

  8. Jeśli po 3 próbach procesor wiadomości nie otrzyma potwierdzenia, wyśle wiadomość FIN, ACK do serwera backendu, aby wskazać, że zamyka połączenie.

  9. Jak widać na przykładowej sesji Wireshark, połączenie z backendem zostało nawiązane (krok 1), ale czas oczekiwania na ustanowienie połączenia SSL został przekroczony, ponieważ serwer backendowy nigdy nie odpowiedział.

Jeśli po wykonaniu czynności opisanych w tym dokumencie stwierdzisz, że błąd uzgadniania TLS/SSL jest spowodowany czasem oczekiwania, przejdź do sekcji Rozwiązanie.

Wykrywanie problemów za pomocą monitorowania interfejsu API

Monitorowanie interfejsu API umożliwia szybkie izolowanie obszarów problemowych, aby diagnozować błędy, problemy z wydajnością i opóźnieniami oraz ich źródła, takie jak aplikacje dla programistów, serwery proxy interfejsu API, cele backendu lub platforma interfejsu API.

Przejdź przez przykładowy scenariusz, który pokazuje, jak rozwiązywać problemy z interfejsami API o kodze 5xx 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 uścisku dłoni SSL występują z powodu ograniczeń zapory sieciowej na serwerze zaplecza, które blokują ruch z Apigee Edge. Jeśli po wykonaniu czynności diagnostycznych ustalisz, że przyczyną błędu uścisku dłoni jest limit czasu, 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óżnych warstwach sieci. Należy upewnić się, że wszystkie warstwy sieci związane z adresami IP procesora wiadomości zostały usunięte, aby zapewnić płynny przepływ ruchu między Apigee Edge a serwerem backendu.

Jeśli nie ma żadnych ograniczeń w firewallu lub problem nadal występuje, przejdź do sekcji Musisz zebrać informacje diagnostyczne.

Musisz zebrać informacje diagnostyczne

Jeśli problem będzie się powtarzał, nawet po wykonaniu powyższych instrukcji, prześlij te informacje diagnostyczne. Aby uzyskać pomoc, skontaktuj się z zespołem pomocy Apigee Edge:

  1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
    1. Nazwa organizacji
    2. Nazwa środowiska
    3. Nazwa proxy interfejsu API
    4. Pełny polecenia 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 Private Cloud, podaj te informacje:
    1. Pełny komunikat o błędzie
    2. Pakiet serwera 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 przez serwer backendu lub procesor wiadomości.
  3. Szczegóły dotyczące tego, które sekcje tego przewodnika zostały wypróbowane, oraz inne informacje, które pomogą nam szybko rozwiązać problem.