502 Nieprawidłowy limit czasu bramy

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

Krótki opis problemu

Aplikacja kliencka otrzymuje błąd 502 (Nieprawidłowa brama). Procesor 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ć następujący komunikat o błędzie:

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

Możliwa przyczyna

Możliwą przyczynę tego problemu znajdziesz w tej tabeli:

Przyczyna Opis Czynności, które należy wykonać, aby rozwiązać problem
Upłynął limit czasu uzgadniania połączenia 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: przekroczenie 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 Edge 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. Zostaną wyświetlone instrukcje dotyczące Edge Private Cloud i Cloud Public Cloud.

Analizowanie danych wyjściowych sesji śledzenia

W następujących krokach opisano, jak przeprowadzić wstępną diagnostykę problemu za pomocą narzędzia Apigee Edge Trace.

  1. W interfejsie Edge włącz sesję śledzenia dla serwera 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ą tego błędu jest to, że zapora sieciowa serwera zaplecza blokuje ruch z Apigee.

    1. Sprawdź, czy błąd 502 Bad Gateway występuje po 55 sekundach, czyli po domyślnym czasie oczekiwania ustawionym w procesorze wiadomości. Jeśli widzisz błąd wystąpił po 55 sekundach. Oznacza to, że przekroczono limit czasu prawdopodobną przyczynę problemu.
    2. Sprawdź, czy błąd wskazuje na błąd: messaging.adaptors.http.BadGateway. Ten błąd również zazwyczaj oznacza przekroczenie limitu czasu.

    3. Jeśli korzystasz z Edge Private Cloud, zwróć uwagę na wartość atrybutu X-Apigee.Message-ID w danych wyjściowych logu czasu, jak pokazano poniżej. Prywatny Użytkownik Google Cloud może użyć tego identyfikatora, aby rozwiązać dalsze problemy, zgodnie z opisem poniżej.

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

      2. Przewiń w dół i zanotuj wartość pola o nazwie 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 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 sprawdź plik dziennika usługi Przetwarzanie wiadomości pod kątem odpowiednich informacji. 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 backendu obsługuje pojedynczy adres IP, użyj tego polecenia:

      telnet BackendServer-IPaddress 443

    2. Jeśli serwer backendu obsługuje kilka adresów IP, użyj w poleceniu 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 protokołu. Otwórz plik:

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

    i wyszukaj unikalny identyfikator wiadomości (wartość X-Apigee.Message-ID), znalezione w pliku śledzenia). Sprawdź, czy pojawia się komunikat o błędzie uzgadniania połączenia następującym identyfikatorem wiadomości:

    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 w pliku dziennika procesora wiadomości zobaczysz ten błąd, przeprowadź dalsze dochodzenie. Zapoznaj się z artykułem Dalsze kroki diagnostyczne dla użytkowników Edge Private i Cloud Public Cloud.

Jeśli w pliku dziennika nie widzisz komunikatu o uścisku dłoni, przejdź do sekcji Niezbędne zbieranie informacji diagnostycznych.

Dalsze kroki 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 usługi 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 zaplecza, użyj w komendzie tcpdump publicznego adresu IP procesora wiadomości. Aby uzyskać pomoc w korzystaniu z do badania ruchu na serwerze backendu, patrz tcpdump.

    • Jeśli pobierasz pakiety TCP/IP w procesorze wiadomości, użyj protokołu publicznego Adres IP serwera backendu w poleceniu tcpdump. Pomoc przy korzystaniu z tego polecenia aby zbadać ruch związany z procesorem wiadomości, zobacz 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 znajdziesz na stronie tcpdump. w przypadku innych wariantów tego polecenia.

  4. Przeprowadź analizę pakietów TCP/IP za pomocą narzędzia Wireshark lub podobnym narzędziu. Na poniższym zrzucie ekranu widać pakiety TCP/IP w Wireshark.

  5. W wyjściu Wiresharka widać, że 3-kierunkowe uścisk dłoni TCP kończy się pomyślnie w pierwszych 3 pakietach.

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

  7. Ponieważ nie ma potwierdzenia od serwera zaplecza, procesor wiadomości wielokrotnie retransmituje wiadomość „Client Hello” w pakietach 5, 6 i 7 po odczekaniu zdefiniowanego wstępnie 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 nawiązanie połączenia SSL został przekroczony, ponieważ serwer backendowy nigdy nie odpowiedział.

Jeśli wykonasz kroki rozwiązywania problemów opisane w tym poradniku i stwierdzisz, że z powodu przekroczenia czasu oczekiwania spowodował błąd uzgadniania połączenia TLS/SSL, przejdź do sekcji Rozwiązanie.

Wykrywanie problemu przy użyciu monitorowania interfejsów API

Monitorowanie interfejsów API umożliwia izolowanie szybko diagnozować błędy, wydajność i czas oczekiwania oraz takie jak aplikacje dla programistów, serwery proxy interfejsu API, miejsca docelowe backendu czy platforma API.

Przejdź przez przykładowy scenariusz, który pokazuje, jak rozwiązywać problemy z interfejsami API o kodach 5xx za pomocą monitorowania interfejsów API. Możesz na przykład skonfigurować alert, który będzie Cię powiadamiał, gdy liczba Błędy messaging.adaptors.http.BadGateway przekraczają określony próg.

Rozdzielczość

Przekroczenie limitu czasu uzgadniania połączenia SSL następuje zwykle z powodu ograniczeń zapory sieciowej na serwerze backendu, który blokuje ruch z Apigee Edge. Jeśli obserwujesz i ustaliliśmy, że przyczyną błędu uzgadniania połączenia musisz skontaktować się ze swoim zespołem ds. sieci, aby znaleźć przyczynę i naprawić błąd ograniczeń zapory sieciowej.

Pamiętaj, że ograniczenia zapory sieciowej mogą być nakładane na różne warstwy sieci. Należy upewnić się, że ograniczenia na wszystkich warstwach sieci zostały usunięte, do adresów IP procesora wiadomości, aby zapewnić płynny przepływ ruchu między Apigee Edge i serwer 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 czynności, prześlij te informacje diagnostyczne. Skontaktuj się z nimi i udostępnij je zespołowi pomocy Apigee Edge:

  1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
    1. Nazwa organizacji
    2. Nazwa środowiska
    3. Nazwa serwera proxy interfejsu API
    4. Pełny polecenia curl do odtworzenia błędu
    5. Plik śledzenia pokazujący błąd
    6. Pakiety TCP/IP przechwycone przez serwer backendu
  2. Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:
    1. Zaobserwowano 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ółowe informacje o wypróbowanych przez Ciebie sekcjach tego Poradnika i wszelkie inne informacje, które pomogą nam szybciej rozwiązać ten problem.